linux-kernel - Re: [PATCH 3/3] Makes lguest's irq handler typesafe

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47915515.1020905@gmail.com>
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/