Farid Hajji farid.hajji@ob.kamp.net writes in l4-hurd:
[...]
The second pressing point is to write/port a very small subset of device drivers to L4. We need a native L4 driver for ATAPI (or SCSI?) disks, so that the pager can use a real disk as backing store, and so that we can port a filesystem as well ;). Here too, no-one volunteered yet.
We in Dresden have extensive experience in porting Linux device drivers to run directly on top of L4, so if you guys have questions, don't hesitate to ask on the L4-hackers mailing list l4-hackers@os.inf.tu-dresden.de.
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.
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 use. I even wrote a technical report on it: URL:http://os.inf.tu-dresden.de/~hohmuth/prj/oskit-l4.ps.gz.
(You can find this and other reports in the L4 Developer's bibliography at URL:http://os.inf.tu-dresden.de/L4/bib.html.)
Michael
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? 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?
One example: consider the serial driver. It could be used by the user-level PPP program on *BSD or the Hurd to access one port, and by the gpm mouse handler on L4Linux for the other physical port. Another example: disk drivers could serve filesystems on both L4Linux and the Hurd (as long as the filesystems are not used simultaneously!).
It would be great to have such generally useable drivers resp. driver tasks!
I see some issues on multiplexing and demultiplexing access from or to the drivers here (which resembles accessing Mach devices from multiple Mach tasks in unrelated OSes). Quite interesting!
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*).
use. I even wrote a technical report on it: URL:http://os.inf.tu-dresden.de/~hohmuth/prj/oskit-l4.ps.gz.
I'll read this carefully and will get back to you if necessary ;) Thanks for the hint.
(You can find this and other reports in the L4 Developer's bibliography at URL:http://os.inf.tu-dresden.de/L4/bib.html.)
Michael
hohmuth@innocent.com, hohmuth@sax.de http://www.sax.de/~hohmuth/
-Farid.
l4-hackers@os.inf.tu-dresden.de
-
Farid Hajji -
Michael Hohmuth