OSNews

Our group ported Linux into our environment as a normal userspace application. This version of Linux is called L4Linux and it is binary compatible with plain Linux. With L4Linux you can use all your legacy applications on top of DROPS. You can even run several instances of L4Linux side by side on one machine, creating a virtual-machine-like setup. It is also possible to write L4Linux-programs, which actually communicate with L4-tasks outside of L4Linux. You may find further information about L4Linux here.

Apart from L4Linux we also have a technique called the device driver environment (DDE), which allows us to take Linux device drivers out of Linux and run them directly on our platform. We can even run Linux drivers of different Linux versions side by side. Do you see how that solves the driver problem for our platform? Work is underway to create a device driver environment for BSD drivers, enabling us to make use of even more drivers.

But we take even more value out of Linux. We have ported the Linux TCP/IP stack to run on plain L4, enabling L4 applications to make use of all the virtues of the Internet.

The first one would do is to get the hello world (a simple hello-world application) from public CVS, compile it, run it and see that it doesn't do much more than saying "hello world". However, with this little package you can already learn much about how our system works. You may get it from here.

For easy programming, we have a custom build environment, which can be configured using graphical menus, just like the Linux kernel does. It basically keeps track of all the dependencies and does the build magic for you. All you need is gcc and a recent version of make.

Once you start building more complex environments, you will notice that it is very difficult to keep track of all the dependencies and to configure all the system services to get a working setup. Thus the entry learning curve is high, and it caused me some troubles. However, the problem is well-known and we are working on solutions.

With L4env, programming for our system looks much like programming for any major UNIX. Because we have ported dietlibc and uclibc, there isn't much a C programmer would miss. However, once you start using system services directly you will get into trouble because documentation is sparse and most of the "feel" for the system is taught in lectures.

So as to port dietlibc, a virtual filesystem backend had to be developed. Our solution is called L4vfs, which is completely modular, allowing you to mount different filesystems (called volumes) into your address space. To make use of the filesystem of a running L4Linux instance, I wrote a little L4Linux program (Proxyfs), which acts as a normal volume, is mountable in L4vfs and translates all the filesystem calls into Linux calls. Using this technique, we can use all the filesystems of Linux from native L4 programs without big porting efforts.

Proxyfs is also a good example of an L4Linux task, that is communicating with L4-tasks.

Programming system services is straightforward because all you have to do is to write the interface in an interface definition language (IDL) and implement the methods. All the difficult stuff needed for interprocess communication like marshalling/unmashalling of data is done by communication-stubs created by our IDL-Compiler DICE.

1. "DROPS, 1/3"
2. "DROPS, 2/3"
3. "DROPS, 3/3"