Re: A small article about the Hurd on L4

[Espen Skoglund]

[Wolfgang Jährling]
> Espen Skoglund <address@hidden> wrote:
>> With the current X.2 API you can either 1) implement an interrupt
>> distributor thread which forwards the interruption IPC to the
>> appropriate drivers and handles the interrupt acking/unmasking,

> As we probably want different drivers in different address spaces,
> this might be slow.

Of course.  This was the not-so-very-efficient solution.

> An extra context switch might be neglible compared to the cost of
> manipulating the IRQ controller on IA32, but is this also true for
> an ARM with a decent IRQ controller and a fast bus?

Well, if you talk about the ARM then the IRQ controller really depends
on what type of ARM you're talking about.  Some ARM boards come
shipped with standard PC style IRQ controllers (which you recognize as
being inefficient), others come with other type of controllers.

The point that you seem to avoid, though, is that the extra cost of
sharing interrupts only comes into place if you actually *do* share
interrupts.  If you happen to share interrupts then you either have
one of the interrupt sources which should have a high priority
(relative to the other sources) and could then use interrupt chaining,
have interrupt sources where the extra overhead doesn't really matter,
or have an ill-configured system.  (Shoot me down in flames if you
think I'm wrong.)

>> or 2) implement interrupt chaining where you use propagation to
>> hand off the interrupt to the next driver in the chain if the
>> current driver can not handle the interrupt.  By using propagation
>> the next driver in the chain will then be able to do interrupt
>> acking/unmasking.

> Am I understanding it right that a driver would have to forward it
> himself to the next driver?  If so, we rely on the drivers to be
> cooperative.  While drivers should be trusted, we still want to
> minimize the impact of a buggy driver, and as adding and removing
> drivers will require to update the chain, it looks like complexity
> one might want to avoid.

A driver would indeed have to forward the interrupt to the next driver
in the chain, and this might cause problems if the driver hangs
himself before propagating the interrupt.  However, even if we do not
use the chaining method, we still require an accept/not accept message
from the driver before handing the interrupt over to another driver.
Handing the interrupt over to multiple driver before such an accept
message (i.e., handing it out to multiple drivers simultaneously)
opens up a big can of worms: Who will acknowledge/unmask the interrupt
at the controller level?  The first driver who handles the interrupt
(what about the drivers that have not yet been able to ack the
interrupt at the device)?  The last driver to handle the interrupt
(this will effectively cause time critical drivers to be slowed down
by non time critical ones)?  Then there is the whole overhead of
having all drivers being involved for every IRQ even if 99.9% of the
IRQs need only be handled by a single driver.

Of course, if you want to build a more robust system you might want to
take the extra overhead associated with having some sort of "interrupt
distributor thread" which hands out interrupt request and times out if
a response has not been generated within a given amount of time, and
this might indeed be a good configuration for a development/debugging
system.

As for the chain reconfiguration, this is actually less complex than
it first seems.  There might be a few unneeded propagations going on
in some cases, that's true, but this does not really matter.  There
might also be cases where an interrupt message is not caught by the
appropriate driver, but this does not really matter either (the
interrupt will simply be regenerated, and with a massive number of
incoming interrupts we are likely to loose interrupts at the hardware
level anyway).  The worst thing that could happen is that the driver
currently handling an interrupt message is removed from the chain
before it managed to do an interrupt acknowledge/handover.  However,
this latter problem is trivial to solve using a proper chain removal
protocol.

        eSk