Date:	Thu, 24 Apr 2008 12:16:11 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Rene Herman <rene.herman@...access.nl>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, rmk@....linux.org.uk,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [git patch] free_irq() fixes

Linus Torvalds wrote:
> 
> On Thu, 24 Apr 2008, Jeff Garzik wrote:
>> However, it does not follow that an int is what _must_ be passed around.  We
>> already have design patterns like
>>
>> 	cookie_pointer = ioremap(raw bus resource)
>>
>> Not that I am the one pushing for that, just noting.
> 
> I do agree that we could use something more type-safe.
> 
> So a "pointer" to a structure that doesn't actually exist would be fine 
> and would give us some C type checking. 
> 
> But then you'd have to have some way to "printk" the information, which is 
> a very common requirement (and the printk still needs to be a number, 
> because you want to match up 'dmesg' output with the '/proc/interrupts' 
> file etc).
> 
> That, in turn, would effectively force a whole new function, and then 
> you'd have things like
> 
> 	printk(.. irq %d .., irq_number(irqcookie) ..)
> 
> which while not ugly isn't really all that clean either. And I guarantee 
> that people would misuse that "irq_number(cookie)" exactly in the same 
> ways they'd misuse "irq" (ie not very much).
> 
> Quite frankly, I'd much prefer a
> 
> 	typedef int __bitwise irq_t;
> 
> and then we can use sparse to do this testing, without breaking any 
> existing use at all (because it will still be an "int" to gcc, but sparse 
> will make "irq_t" a type of its own and make sure that people pass it 
> around as such and not do arithmetic ops on it etc).

sparse checking sure would be nice for drivers......


As an aside it would be nice to associate a struct device with an irq at 
request_irq() time.  I wonder if we could perform this transition in 
situ, by creating a dev_request_irq() that used the new irq_t, while 
leaving all existing drivers to be converted as time permits.


>>> EVERYTHING else would be architecture-specific. And that is exactly what we
>>> do not want. EVER. 
>> Not true -- you have metadata/OOB data like MSI messages, where you are passed
>> a value from the PCI hardware in the PCI message, not just an "interrupt
>> asserted" condition.  Or s/value/values/ if you enable PCI MSI's multiple
>> message support.
> 
> The point is, MSI *is* architecture-specific. In fact, it's even 
> motherboard-specific, in that you are going to have (for the forseeable 
> future) drivers that have to work with or witgout MSI even on the same 
> architecture.

Sure, so what would a driver API look like that works for both situations?

We have two models:

     For each interrupt event delivered:

	old model: "irq asserted" datum is passed to driver implicitly,
	via the fact that your irq handler is called.

	new model: we have a dword, or two or three, passed to driver
	explicitly, in addition to implicit "irq asserted" fact

It's easier to handle both models if you could pass something other than 
an int to the driver --for each interrupt event--.

Having something pointer-sized rather than int-sized would be flexible 
enough to cover all situations, now and in the future, presumably.

	Jeff


--
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