Re: [git patch] free_irq() fixes

From: Jeff Garzik
Date: Thu Apr 24 2008 - 11:41:12 EST


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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/