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.thiba...@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-
