Re: user-level drivers

[olafBuddenhagen]

Hi,

On Mon, May 09, 2011 at 11:15:15AM +0200, Thomas Schwinge wrote:
> On Mon, 9 May 2011 00:07:16 +0200, Samuel Thibault <samuel.thibault@gnu.org> 
> wrote:

> > /* Requesting IRQ events on a port */
> > 
> > routine device_intr_notify(
> >                master_port     : mach_port_t;
> >        in      irq             : int;
> >        in      id              : int;
> >        in      flags           : int;
> >        in      receive_port    : mach_port_send_t
> >        );

> Shouldn't all the other ``in data'' items be wrapped in an
> (architecured-dependent) structure similar to what we're doing for I/O
> ports?  Compare io_perm_t in i386/include/mach/i386/mach_i386.defs,
> i386/include/mach/i386/mach_i386_types.h, i386/i386/io_perm.h.  I believe
> this would help to separate implementation details (IRQ number being an
> integer; specific values of flags; etc.) from the RPC mechanism.

Don't overengineer :-) I doubt that there are -- or will ever be -- any
architectures where the IRQ line is not an integer...

Also, as I pointed out in the past, we are not bound by RPC interfaces
forever: we can simply add new ones if the original turns out too
limited after all.

(BTW, I have no idea what the other two parameters mean...)

> 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 tempted to cry "don't overengineer" again... Though I must admit
that -- unlike for I/O ports (where it's totally pointless IMHO) -- this
would actually make sense here: the IRQ enabling is a pretty
time-critical operation (happening on every interrupt received); so it
would be good if a bus manager is able to hand out an enable port to
unprivileged driver processes.

OTOH, this is another thing that can be added (with a new interface)
when it's needed, i.e. when someone steps up to actually implement a bus
manager... I wouldn't bother for now.

-antrik-