Hi Alexander,
I'm currently implementing an X86 PCI bus driver for L4Linux as a temporary solution for getting USB support in L4Linux.
you are taking our port of L4Linux into an interesting direction. So far, we have deliberately kept our version of L4Linux void of any device-driver functionality and used it as a mere runtime environment for Linux programs. Can you give me a bit of background information behind your work? Are you going to use L4Linux as a device-driver OS, providing Genode service interfaces? Or do you just want to grant Linux access to (a subset of) real devices to avoid the need for native Genode device drivers and session interfaces for those devices?
Current genode-side code is presented below. The l4linux patch is not ready, but I've submitted the relevant part of the diff to pastebin (it's only makefile and kconfig anyway)
https://github.com/Ksys-labs/genode/blob/pci_wip/ports-foc/src/drivers/genod... https://github.com/Ksys-labs/genode/blob/pci_wip/ports-foc/src/lib/l4lx/geno... https://github.com/Ksys-labs/genode/blob/pci_wip/ports-foc/src/lib/l4lx/l4_i... http://pastebin.com/9c37tuJR
That looks good to me.
So, the question is, why is interrupt handling broken and the only working interrupt in l4linux is timer which actually uses L4 timer ipc instead of irq and how this should be fixed.
The reason is plain and simply that our version of L4Linux was never meant to access devices directly. I am surprised that you got that far. :-)
Also, what do you think of making a "genode" arch for linux and getting rid of l4linux which uses the Fiasco.OC API bypassing Genode interfaces?
As you described in your article, the current situation is not exactly beautiful. We have a patched version of Linux (L4Linux) with the original git history gone due to L4Linux' way of releasing snapshots via SVN. Then, we put some patches in top, along with a LRre emulation library. Finally, we garnish the whole thing with some Genode-specific stub drivers.
So why have we chosen this path? We thought that this way minimizes our ongoing investment with maintaining the Genode version of L4Linux. TUD is taking care of adapting L4Linux to changes of the Fiasco.OC kernel interface. So we don't have to do that. But TUD is targeting L4Re only and does not care about Genode. So to leverage their work, we need our custom L4Re emulation library, which hopefully is pretty simple (that is actually true) and easy to maintain. This approach worked well as long as we did not do any invasive changes to L4Linux and use it just as is. Now, that you are pushing the boundaries a bit more and making more intensive use of L4Linux, I can clearly see how the construct becomes a burden for you.
Regarding your last question, sure, I would welcome to remove several levels of indirection that we currently rely on. The cleanest solution would certainly be to fork the vanilla Linux kernel and implement paravirtualization using Genode primitives only, thereby taking L4Linux and the L4Re emulation library out of the loop. On the other hand, I cannot really justify putting much effort into that because I regard virtualized Linux just as a stop-gap solution for running existing software until Genode supports it natively. Naturally, I would prefer to dedicate my energy on developing the native Genode environment instead.
Also, for the x86 architecture, there exists the Vancouver VMM, which is not only actively developed in the open but their core developers cooperate closely with us (see https://github.com/genodelabs/genode/issues/666). So for x86 with hardware virtualization, I see no advantage of a paravirtualized Linux over the Vancouver VMM. We can just use Linux unmodified. The only difference is that Vancouver works on NOVA only, not Fiasco.OC ATM.
This leaves only ARM as the target platform where L4Linux seems to be most suitable. However, since Cortex-A15 CPUs come with hardware virtualization support, I find it more tempting to explore this route rather than investing time in pursuing the paravirtualization of the Linux kernel.
That is of course just my line of thinking. If you like to go forward with developing a replacement for L4Linux that removes from the superficial indirections that plague you today, this would be very welcome and I'd certainly provide assistance if needed.
Cheers Norman