Re: how to tell Linux *not* to share IRQs ?

[Eric W. Biederman]

Andrew McNamara <[e-mail]> writes:

> >Chris> Yes, drivers need to check their hardware devices and
> >Chris> acknowledge whether or not it's was their interrupt or not.  It
> >Chris> sounds terrible but even with many thousands of interrupts per
> >Chris> second the cost doesn't seem to be that high.
> >
> >Not only is this the case, it's also the only sane thing to do <tm>,
> >any device driver should check the status of the hardware it is
> >serving before doing anything else.
> 
> That's not necessarily the case - the problem arises due the
> limitations of PC interrupt routing. In an ideal world, the
> interrupting device would be able to be uniquely identified, rather
> than having to poll every device sharing that interrupt.

Interrupts are inherently race, so you still want to check your device
status, even if you get an interrupt.  Having a smaller set of devices
to poll to see if there is any work to do is of course good.
 
> The problem is largely historical - each interrupt traditionally had a
> physically line associated with it, and lines on your backplane were a
> limited resource. 
> 
> If you were to do it again these days, you might have some sort of
> shared serial bus, so devices could give detailed data to the cpu
> (not only to uniquely identify the interrupting device, but also
> identify sub-devices - say a USB peripheral).

I don't know.  The ISA bus was structured somewhat like you describe
and that is what is truly legacy at the moment.  I suspect
the one line per interrupt came of wanting to reduce latencies.

Though when you start think of things like the current ioapics where
you do get a serial bus for your interrupts anyway.  A shared serial
bus probably makes sense.

On the other side I think having drivers that can share interupts is a
very healthy thing so I'm not certain I would want to discourage that.

Eric