Re: Change in [request,free]_irq() (fwd)

Hans-Georg von Zezschwitz (
Fri, 5 Apr 1996 00:25:52 +0200 (MET DST)

In advance: All I know is 'cause I asked the same two weeks ago...

> Can anyone document this change at all? What does it do and why was it
> changed? All I can tell is that there's an extra parameter (void
> *dev_id) being passed. This parameter doesn't seem to be documented
> anywhere in the source tree.

Just think of it as an identifier. If you look at the patch when it
was introduced (patch-1.3.70.gz), you will find out that most calls
to request_irq and free_irq in the different driver just appended
a NULL-pointer as last argument. This should work for DOSEMU, too -
it's the way I compiled it when moving beyond 1.3.70.

But instead of "hardcoding" it, you will make dosemu to compile
with versions before 1.3.70 and after 1.3.70 by adding something
like this:

#if LINUX_VERSIONCODE < 0x010346 /* before 1.3.70 */
request_irq ( ... /* old parameters */ );
request_irq ( ... /* old par's */, NULL);

The device-id is passed whenever the interrupt handler is called
(You will notice another parameter introduced there, too).
You might ignore it in the interrupt handler - nothing (worse) will
happen. The only way the kernel uses it is that you have to pass
the same device-id when you call free_irq. By that, you have the
first (minor) advantage - a buggy driver you are e.g. writing will
not be able to accidently release the hard-disk irq - as long as it
does not accidently pass the device id of the harddisk driver.
(As most drivers are using NULL as device_id at the moment, you will
anyway most likely be able to release a wrong irq).

But mostly, this concept was introduced together with the introduction
of "shared interrupts". The idea is that several devices may agree to
share the same irq-line. (By now, this is not yet used in normal
kernel drivers (I might be wrong)).

If several devices register their handlers on the same irq-line,
how shall they tell the kernel they want to unregister if the
kernel only gets the irq-number to which the handler belongs, but
not the handler-address itsself?

Moreover, think of serial cards with e.g. 4 IRQ-lines for four ports
(you know, the cheap ones :-) ). They all could share the same
irq-handler and pass a hardware-description-address as device id.
When the handler is called, it does not have to look up the correct
hardware/buffer-structure by looking at the irq, it gets it passed

Thanks to Linus who explained this to me.