lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 19 Jan 2008 10:40:37 +0900 From: Tejun Heo <htejun@...il.com> To: Rusty Russell <rusty@...tcorp.com.au> CC: linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, Jeff Garzik <jgarzik@...ox.com>, Ash Willis <ashwillis@...grammer.net>, linux-pcmcia@...ts.infradead.org, virtualization@...ts.linux-foundation.org Subject: Re: [PATCH 3/3] Makes lguest's irq handler typesafe Hello, Rusty. Rusty Russell wrote: > On Saturday 19 January 2008 10:12:33 Tejun Heo wrote: >> Type safety is good but I doubt this would be worth the complexity. It >> has some benefits but there's much larger benefit in keeping things in >> straight C. People know that functions take fixed types and are also >> familiar with the convention of passing void * for callback arguments. >> IMHO, staying in line with those common knowledges easily trumps having >> type checking on interrupt handler. > > I sympathise with this argument, but I think just because people are familiar > with existing hacks shouldn't prevent improvement. I think the resulting > code is clearer and more readable. > > Even in the implementation, the tricky part is the check_either_type() macro: > the rest is straight-forward. The change is a small one and both the cost and benefit aren't big. >> Also, how often do we see a bug where things go wrong because interrupt >> handler is given the wrong type of argument? Even when such bug >> happens, I doubt it can escape the developer's workstation if he/she is >> paying any attention to testing. > > I agree this one is unlikely. But I am trying to spread type-safety more > widely (see previous kthread patches). > > I like changing the kernel to make life simpler for developers. We don't do > enough of it. I'm in full agreement here but the cost / benefit equation doesn't seem quite right to me. If we're gonna convert all callbacks to take native pointers, I'm fine with the irq handler part too. If not, it just adds confusion which is much worse than any benefit it can bring, so I think the question is "do we want to change all callbacks to take native pointer type instead of void pointer?". -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists