Messages in this thread | | | Date | Sat, 16 Mar 1996 12:41:29 +0200 (EET) | From | Linus Torvalds <> | Subject | Re: Wrong use of IRQ-handling in ftape? |
| |
On Fri, 15 Mar 1996, Hans Georg Zezschwitz wrote: > > As writing a section of the Kernel Korner in Linux Journal, I wondered > what the new "device id" meant. > > As Shared Interrupts are a concept supported by PCI, which introduces > device ids as well, I saw those to concepts together and believed > that the device id should is only useful when SA_SHIRQ is set (when > calling request_irq). Howether, when looking at patch-1.3.74.gz, I > noticed that the calls to "request_irq" and "free_irq" don't support > shared irqs, but anyway set the device id. This should not be > harmful, but who understood the new irq-concept wrong, me or the > "patcher"?
"dev_id" can be anything, and as far as the rest of the kernel is concerned it just has to be a unique pointer within each interrupt. For most things, that unique pointer might as well be NULL (if you aren't sharing interrupt NULL is as unique as anything else), and that's what most drivers use now.
However, the nice thing about "dev_id" is that it's not only used to separate two irq handlers from each other at request/free time, it's _also_ given to the interrupt handler routine when it's called. And that makes it useful even for interrupts that can't be shared: it can be used as a pointer to the device structure.
(the current networking drievrs usually use something like "irq2dev[irqnr]" to get at the device structure for that interrupt, but it would be more efficient to just give the device structure pointer as "dev_id", and use that instead..)
The ftape driver uses a pointer to a string, which works but doesn't make much sense (they might as well use NULL, the rest of the kernel doesn't care what it is, and they aren't sharing interrupts anyway, I believe). But it's not wrong, it's just unnecessary.
Linus
| |