Hello Johannes,

On Tue, Mar 13, 2018 at 01:36:09PM +0100, Johannes Kliemann wrote:

I'm currently implementing the IRQ session on base-linux. If I understood the Foundations book correctly interrupts are waiting in a separate thread that locks when it is waiting and continues (and calls the handler) once an interrupt is triggered.

The core-internal implementation depends on the base platform. On NOVA and FOC, the Irq_object (which is a thread) is never started, ie., does not execute an entry function. Other platforms (e.g., OKL4) use the Irq_object thread to implement a interrupt-wait-and-signal loop.

According to this I have implemented a kernel module [1] that triggers interrupts via reads on a device file. The interrupt can be registered via ioctl on the file descriptor and the a blocking read is called that returns once the registered interrupts has been triggered.

I have looked into the implementations of base-nova and base-hw but didn't completely understand it. As far as I understood the session component implements the session and only requires the interrupt number and a signal handler. The Irq_object implements the waiting thread but I didn't see where it is waiting for the interrupt. Also as far as I could see it the actual interrupt capability stays inside the session in core and only the signal handler capability is passed to the component.

I suggest you refer to OKL4

base-okl4/src/core/irq_session_component.cc

and implement an Irq_object working similarly with a entry() function that uses Irq_object::_wait_for_irq() (which blocks in read(dev_fd)) and signals IRQ occurence by Genode::Signal_transmitter(_sig_cap).submit(1)

Is my understanding of this correct? And is there any further documentation on this?

Unfortunately, there's only few documentation of the core internals. To get up-to-date information I suggest looking at the code and asking here or even on Freenode

http://webchat.freenode.net/?randomnick=1&channels=%23genode&uio=d4

Regards

Hi Johannes,

El 13/03/18 a las 13:36, Johannes Kliemann escribió:

Hi all,

I'm currently implementing the IRQ session on base-linux. If I understood the Foundations book correctly interrupts are waiting in a separate thread that locks when it is waiting and continues (and calls the handler) once an interrupt is triggered.

According to this I have implemented a kernel module [1] that triggers interrupts via reads on a device file. The interrupt can be registered via ioctl on the file descriptor and the a blocking read is called that returns once the registered interrupts has been triggered.

I have looked into the implementations of base-nova and base-hw but didn't completely understand it. As far as I understood the session component implements the session and only requires the interrupt number and a signal handler. The Irq_object implements the waiting thread but I didn't see where it is waiting for the interrupt. Also as far as I could see it the actual interrupt capability stays inside the session in core and only the signal handler capability is passed to the component.

Is my understanding of this correct? And is there any further documentation on this?

On base-hw, the IRQ session component of Core merely assigns the IRQ to the client and forwards the clients signal capability and ack calls to the kernel (allow the IRQ to trigger again). The Kernel IRQ-object is created and bound to the clients signal context as soon as the client calls Irq_session::sigh. From this moment on, the kernel directly communicates the IRQ to the client through the signal context without going over Core. So to the user, the IRQ session only comes into play when requesting/releasing the interrupt and when acknowledging it. The handling is achieved through the Signal_handler implementation. To be more precise, the waiting is done by the component-local signal-handler thread which dispatches the signals to RPCs on the your entrypoint thread. All this happens behind the interface of the Genode Component environment and shows up to you only as calls to the handler.

This simple IRQ-session-component implementation is based on the fact that base-hw was explicitely designed to work together with the Genode Core/Userland. Thus, I don't know how far you can get with it on a third-party kernel.

Cheers, Martin