[cgl_discussion] Re: AEM calls to do_event()

Dave Olien dmo at osdl.org
Mon Mar 24 15:07:07 PST 2003

On Mon, Mar 24, 2003 at 09:22:24AM -0500, Frederic Rossi (LMC) wrote:
> Regarding do_event in interrut, theoretically you're right. Also it's 
> not possible
> to deliver event in interrupt. But I want this for light management and 
> it can be
> ignored for the moment since it is not used yet (do_event simply returns).

I suspected that might be the intent.  Lots of people would be
pretty sensitive about putting any extra code in that path, though.

It would be nice if there were a way to register your handler onto the
front of the handler list for every IRQ.  This would be a way to
make the function less of a kernel patch, and more something that
could be loaded as a module.

Unfortunately, IRQ registration currently is done in the order
devices are discovered.  Plus, some devices are apparently unable
to share IRQs.  So, this would require modifications to the kernel's
IRQ registration interfaces.

Just "thinking aloud"...

> On the other hand, signal delivery and event delivery are actually the same
> sequence of: save context, change eip, iret.
> Now  I've already though of some merging between some AEM code  and the 
> kernel
> code. The signal code is probably the perfect case. We could have some 
> common
> code (let's call it callback.c) taking care of building handlers 
> parameters, defining an
> alternative stack if needed and executing a function in user space for 
> either signals
> or events. This would combine features of both. But the signal code is 
> pretty difficult
> and dangerous to change without any good reasons.
> If you have some ideas on this, you are welcome.

There might be other advantages to some kind of integration with
signals.  For example, debuggers could respond to an event notification
just like it responds to a signal.  The target process could stop and
be traced.  Or, you could have the debugger post events to a process.

Again, just thinking out loud..

> Frederic
> Dave Olien wrote:
> >I'm looking at source code a little.
> >
> >I notice that you call do_event() from the assembly code in entry.S
> >in the ret_from_sys_call: code path.  This catches all the cases
> >returning from kernel to user mode, either at the end of:
> >
> >	lcall7
> >	lcall27
> >	an system call,
> >	an exception,
> >	an interrupt,
> >	context switch
> >
> >and pretty much all other cases where the kernel is returning from
> >kernel to user mode.  This is very similar to signal delivery.
> >
> >I notice you also have a call to do_event() on ENTRY to the
> >kernel at interrupt time.  In hw_irq.h, the BUILD_COMMON_IRQ() macro
> >now includes a call to do_event() in the assembly language prologue to
> >every interrupt handler.
> >
> >This case seems unneeded.  It's adding to the interrupt handling
> >code path, and gets called before the interrupt handler itself,
> >so it increases interrupt latency.
> >
> >You can't actually deliver an event until you return to user mode
> >anyway, correct?
> >
> >What does this do_event() call accomplish that won't be done later anyway
> >in entry.S?
> > 
> >
> _______________________________________________
> cgl_discussion mailing list
> cgl_discussion at lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/cgl_discussion

More information about the cgl_discussion mailing list