base-linux IRQ session

Martin Stein martin.stein at ...1...
Wed Mar 14 17:05:46 CET 2018


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




More information about the users mailing list