olafbuddenha...@gmx.net, le Tue 24 May 2011 12:09:08 +0200, a écrit : > > 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.
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? Samuel
