extend signal and event notification mechanisms

[rottaran]

This is needed for trap handling, interrupt handling, and generally any signalling between kernel objects and user space as well as between user space threads (execution contexts). Solution to issues #77, #76, #75.

A Signal is pushed from a ISignalSource to a ISignalSink. A source can keep track of multiple sinks. Each sink observes just a single source. Thus, the Signal does not need to convey context information about the source. Signals are 64bit values although 32bit would be good enough probably. The sink could forward a user-supplied value to its source, see EventPair in Fuchsia/Zircon. The sink implementation provides the list handle for the source's list.

A KEvent is pulled by a IKEventSink from a _IKEventSource. A sink can keep track of multiple sources. Each source notifies just a single sink. This, the KEvent has to convey context information about the source to the sink. This is achieved by a user-configurable context value. The combination of user context and event data is designed such that it can be forwarded to the user-space. The KEvent contains the 64bit user-context and the 64bit signal value. The source implementation provides the list handle for the sink's list.

Examples for ISignalSource

• ExecutionContext: trapped, running, suspended, resumed, ...
• Interrupt sources: IO devices, timers, user-defined IPIs, perfomance counter interrupts, ...
• communication channels, see Fuchsia/Zircon for ideas

Examples for ISignalSink

• SignalListener: buffers signal values by bitwise OR, translates into a KEvent, behaves as array of binary semaphores
• (future work) ExecutionContext: receive wakeups such as the Notified in simple semaphore-alike wait/notify support for execution contexts #9, could directly wait/listen on a single ISignalSource similar seL4 with multiple TCBs waiting on the same notification object.

Examples for IKEventSource

• SignalListener
• Portal
• (future work) Endpoint

Examples for IKEventSink

• ExecutionContext: deliver events to the user space without loosing events from different sources.
• (future work) shared memory event queue

Should SignalListener reset it's state on delivery of the KEvent or should the reset be a explicit invocation from user-space? Explicit user-initiated reset is less surprising. Could be done configurable in the kernel object.

implementation steps

• review how the queue of pending KEvents works and update the specification.
• create interfaces in objects/common
• implement ISignalSource in ExecutionContex for emitting trap signals
• rename and clean up INotifiable into IKEventSink (impacts Portal and EC)
• rename and clean up INotification into IKEventSource (impacts Portal and EC)
• implement SignalListener
• implement factory for SignalListener
• implement user-space proxy for SignalListener (user context for SignalListener in KEventHandler)

[rottaran]

Created branch i204_signal and first interface definitions in commit 1602f6c

[rottaran]

We forgot how the interaction between IKEventSource and IKEventSink actually works, for example between Portal and ExecutionContext. The source is put in the sink's queue of pending events. However, not by binding based on an invocation but when the source has something to deliver to the sink. This is the push aspect of the mechanism. And later, when the sink is ready to forward an event, it is dequeing the next source, calling its deliverKEvent() method to retrieve the current value, and forwarding this value then.