Re: [cdi-devel] Interrupts

[Matthew Iselin <matthew@xxxxxxxxxxxxxx>]

On Sun, Jan 17, 2010 at 9:03 PM, Kevin Wolf <kevin@xxxxxxxxxx> wrote:
> Hi all,
>
> I'm currently implementing CDI for a small monolithic kernel. Besides
> getting drivers, my goal in doing so is to find pontential problems with
> CDI. I think with interrupt handling I've found a first thing that needs
> clarification on what drivers can expect. In particular, I remember
> Matt's change to pcnet to use cdi_wait_irq instead of doing it manually.
>
> So the question is: Has pcnet ever been right in doing it manually? Was
> it just ugly or was it wrong?

I would say that pcnet's implementation of its own solution when
cdi_wait_irq already exists was fundamentally wrong. There is no point
reinventing the wheel in each driver when you already have the
functionality available in the interface.

> The point is that currently in my kernel CDI drivers generally run with
> IRQs turned off as the kernel lacks proper locking, so I'm not sure what
> would happen if I would allow IRQs in any place (or even let it be
> preempted). So pcnet would wait forever for an IRQ to happen.

Perhaps cdi_wait_irq needs a timeout parameter. This way we can also
enforce a decent timeframe in which an IRQ should occur, and avoid the
case where a driver hangs because an IRQ never arrives.

> What do you think? Do all other OSes implementing CDI so far allow IRQs
> at any time or does it just happen to work? (I think meanwhile all
> drivers are well-behaved and don't do it manually)

Drivers that use interrupts should be able to assume interrupts are
enabled and working properly. The alternative is to have a function
such as cdi_irqs_enabled (probably not called that though) that the
driver can call and determine if it should poll or wait for an IRQ.
This would probably create multiple code paths for each driver
however, and I feel that IRQs are one of the most basic (and required)
elements of any operating system.

Cheers,

Matt