Farid Hajji farid.hajji@ob.kamp.net writes:

...

Currently, some of my colleagues are working on a framework that allows you to (more or less) drop a Linux driver in a preconfigured source tree and get a working driver that runs on the x86 L4 kernels (L4/x86, Fiasco, L4KA). This framework, which will work with the L4Env environment we're developing, is not quite ready yet, but it might be worth the wait.

Will the drivers run in userland on top of a vanilla L4 kernel?

Yes, they will.

I'm wondering wether it would be possible to use (RPC?) the driver tasks directly from OS personalities like L4Linux, (L4BSD if someone wants to repeat the Lites experience on L4 ;-)) or the Hurd, possibly even simultaneously?

Yes. We have been working on stub drivers for L4Linux that use external user-level drivers concurrently with (non-Linux) tasks. I'm not sure right now which stub drivers we currently provide, but I believe we already support console drivers and block-device drivers.

...

As an alternative, consider using the OSKit. We have developed a compatibility library that allows you to run applications using the OSKit (including the OSKit's device drivers) on top of L4. This work is a bit unpolished and the drivers are slow, but it's quite easy to

Good point. However, wouldn't it be necessary to link the driver libs to the Kernel? This is exactly what we want to avoid in the OSKit-Mach case sometime in the future (*Sigh*).

No, the drivers run completely on user level.

The OSKit has well-defined interfaces for low-level OS services such as IRQ allocation and delivery. Reimplementing these interfaces for a target system such as L4 (in particular parts of liboskit_dev and liboskit_kern) makes it possible to port OSKit drivers to the target system. OSKit drivers do not care whether they run on user level or in kernel mode if all services they expect from liboskit_dev and liboskit_kern are available.

Michael