Re: [git patch] free_irq() fixes

[Jeff Garzik <jeff@garzik.org>]

Linus Torvalds wrote:
> The absolutely _only_ piece of reliably information we have that is 
> architecture- and irq-controller neutral is the exact information we pass 
> in to "request_irq()". That is: irq number, the name, and the device 
> cookie thing. Nothing more.

Agreed.

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.

Overall this is all wild-assed speculation based on a thought 
exploration (#irq-remove) that a several kernel hackers seemed to like.


>  - the "device cookie". This is the thing that the system itself doesn't 
>    care about, and is _entirely_ under control of the driver, so the 
>    driver can pass its own interrupt controller some helpful instance 
>    pointers.
> 
> So of the three, "device cookie" is the one that we absolutely have to 
> have. The irq number is not necessary, but it does actually have some 
> meaning especially for legacy devices (eg ISA), and it is at least 
> _sensible_ to pass around (ie it has no downsides, and it's not 
> fundamentally broken). And the name would be just stupid.

Agreed.


> 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 PCI devices themselves are moving from sending a single bit of 
information ("irq!") to sending actual messages.

That is not arch-specific at all, but a new model for "interrupt" (i.e. 
event) notification being pushed upon us.

	Jeff