[cgl_discussion] Re: AEM calls to do_event()

Frederic Rossi (LMC) Frederic.Rossi at ericsson.ca
Wed Mar 26 04:52:20 PST 2003


Dave,

    Thanks for the suggestions.

Frederic


Dave Olien wrote:

>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