Hi there.
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?
The start point of of this story is a need to use a smart-card reader on top of USB. We had two possibilities: 1. Move crypto applications from L4Linux as dedicated server and connect him with dedicated USB host driver. (it's a right approach) 2. Grant L4linux possibility to communicate with real HW. (it's other approach)
For simplicity let us say that we need to use proprietary Linux binaries without sources which communicate with smart-card reader directly. And then, the first approach is not for us.
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.
Agree.
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.
As I said at FOSDEM'12, the popularity of the platform depends on the ability to re-use old code. If porting takes considerable time, the first - it is expensive, and the secondly could lead to the fact that such a device or HW-SW complex will never seen release due to obsolescence. And re-using is most important thing for me, when i start to develop a new device.
I agree that would be worth L4Linux seen only as a sandbox for Linux binaries execution. Again, ideologically correct exclude drivers from L4Linux. But there are some problems. In addition to the noticed above there is another one. Is is a performance. Now we make some experiments with L4linux as gateway with two dedicated NIC drivers and L4Linux. And we see that the performance degradation is around 85% in contrast with Linux. That is too much, and if it turns that the moving NIC driver back to L4Linux ( ie if we give acces L4Linux network driver to HW) can decrease performance degradation (security architecture allows to do it), we will use this approach.
And oddly enough, the applications for the ARM easier develop from scratch and not use L4Linux for binaries execution. While software for network equipment, based on x86, increasingly require re-using. We have not looked NOVA and Vancouver yet. If we can not solve performance problems with L4Linux we will "taste" them.
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.