[cgl_discussion] Re: AEM calls to do_event()

[Frederic Rossi (LMC)]

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).

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.

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?
>  
>