Re: user-level drivers

[olafBuddenhagen]

Hi,

On Tue, Aug 23, 2011 at 03:22:06AM +0200, Samuel Thibault wrote:

> > > What about using the I/O port scheme?  That is, decide_intr_notify
> > > doesn't enable IRQ notifications, but instead just returns a
> > > handle (compare i386_io_perm_create) that is then passed to
> > > device_irq_enable to enable/disable IRQ notifications (compare
> > > i386_io_perm_modify). Does that make sense in this IRQ scenario?
> 
> I'm having a look at this thread again, and wondering (once more, I
> have to say I don't know so much about the Mach IPC): couldn't the irq
> enabling simply done by an answer to the notify? Or are notifies never
> replied to?

I don't think there is a formal notion of "notifies" in Mach. It's just
a kernel-initiated RPC -- similar to those in the pager interface.

Anyways, this scheme would require the kernel to create a reply port,
along with an appropriate session structure so it knows what to do when
the reply arrives. This is probably still simpler to implement though
than the handle scheme described above... And the possible overhead from
allocating the extra reply port is probably negligible, as this happens
directly in the kernel.

Another thing perhaps worth considering is that some day we might decide
to support shared interrupts. One way of implementing that is to notify
the possible drivers one after the other. (Apparently that's what Minix3
does in the end.) In that case we would actually need the reply anyways,
so the driver can tell the kernel whether it feels responsible for the
interrupt and has acknowledged it in the device, so the kernel can
reenable the IRQ line and be done with it; or whether it has to notify
the next driver instead.

Not sure though whether it's worthwhile considering this possible future
use case right now. If we ever do actually implement shared interrupts,
it's perfectly possible that we decide actually to go with a different
scheme, where the decision which driver is responsible is performed
in-kernel with some kind of bytecode... I guess it's a case of YAGNI.

-antrik-