Re: Wrong use of IRQ-handling in ftape?

Linus Torvalds (torvalds@linux.cs.helsinki.fi)
Sat, 16 Mar 1996 12:41:29 +0200 (EET)


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