Question on omega0

[Vasileios Anagnostopoulos]

Wow, thank you very much for the explanation

Regards
Vasileios

> Hello Vasileios,
>
>> this is my first posting. I was reading the interesting paper "Omega0: A
>> portable interface to interrupt hardware" . I would like to ask if there
>> is any implementation for this paper and if it is adapted to the Intel
>> IOAPIC specification
> an Omega0-like service is included in Genode's core component. It
> completely hides kernel-specific details. The service is called IRQ and
> has a very simple interface (much simpler than the original Omega0 design):
>
>
> http://genode.org/documentation/api/static_content/code/base/include/irq_session/irq_session
>
> Attaching to an IRQ is done by opening a session to the IRQ service and
> supplying the IRQ number as session argument. To wait for an IRQ, the
> client performs a synchronous RPC ('wait_for_irq'). By invoking this
> function, the respective IRQ gets unmasked at the IRQ controller (how
> exactly depends on the kernel and the hardware). The 'wait_for_irq' call
> blocks until an IRQ occurs. Analogously to unmasking the IRQ on the
> 'wait_for_irq' call, the IRQ gets masked when 'wait_for_irq' returns.
>
> This implementation overcomes two problems described in the original
> Omega0 paper. First, the IRQ service can be resolved using the normal
> Genode session mechansim. No special name service or magic is needed.
> Second, a vanishing driver gets detected implicitly by Genode's
> session-close mechanism.
>
> However, one disadvantage of Omega0 prevails: For each IRQ, there is an
> additional hop between the kernel and the IRQ-handling device driver.
> However, depending on the used kernel, this issue can be alleviated. For
> example, on NOVA, the first 'wait_for_irq' call could map the kernel's
> IRQ semaphore to the client. The client could then block directly using
> this kernel object. For the driver implementation, this optimization is
> completely transparent. (Note that is optimization is not implemented
> yet but for reference, a similar approach is already employed by the
> NOVA-specific SIGNAL service)
>
> Regarding shared interrupts, we have addressed this issue on OKL4 (but
> our solution is not limited to this kernel): Multiple clients are able
> to open an IRQ session with the same IRQ number. The respective IRQ gets
> unmasked as soon as all clients have called 'wait_for_irq'. This may be
> a problem if one of those drivers is bugged. If such a driver refuses to
> call 'wait_for_irq', no other driver attached to the same IRQ will
> receive interrupts. However, this problem is inherent to shared IRQs.
>
> Last, IOAPIC support is currently provided by the NOVA and Fiasco.OC
> kernels. On these kernels, the legacy PIC IRQ numbers are not used
> anymore. Instead, each IRQ source is referred to by a so-called global
> system interrupt (GSI) number. However, the first 15 GSIs are normally
> corresponding to their respective PIC numbers (except for the timer that
> moved from IRQ 0 to GSI 2). On Genode, we have not yet implemented
> general support for GSIs except for the remapping of the timer
> interrupt. In the future, we plan to let core's IRQ session take
> kernel-native IRQ numbers (in the case of NOVA and Fiasco.OC that would
> be GSIs) as argument and perform the remapping of IRQ-session arguments
> according to the system's IRQ routing in a separate service. This
> service would intercept the creation of IRQ sessions and perform the
> needed translation.
>
> Best regards
> Norman
>