L4VFS - L4 virtual file system layer

Welcome to the interactive demonstration of L4VFS, the virtual file system layer for DROPS (The Dresden Real-Time Operating System).

L4VFS is a set of so called backends, which are typically combined with a C library. In DROPS these backends provide the functionality that is usually found in the kernel of monolithic operating systems, such as Linux.

To be more precise, L4VFS consists of a set of client-side libraries providing functions at system call level (e.g., open() and read()). Additionally, L4VFS comprises a set of interfaces defining the interaction between the mentioned client-side libraries and corresponding servers. A set of servers providing basic file and network functionality completes the picture. Besides the file system backends, which we refer to under the name L4VFS, we also use other backends, for instance for memory management, time access and logging.

In this demonstration, we are going to have a look at some scenarios, such as a terminal server, readline support on top of L4VFS and file system browsing.

History

L4VFS was born in 2003 in a need to underpin many functions from the dietlibc port to L4 done in 2003. Later we also ported the uCLibc, and L4VFS is also available here. Since then we improved L4VFS incrementally as the need arose.

Martin Pohlack started the project, defined the overall architecture and implemented many backends and servers. He is currently coordinating the project.

Björn Döbel was heavily involved in the development of the term server, signaling support, and left his traces all over the project.

The following (not complete) list contains names of contributors to L4VFS: Alexander Böttcher, Adam Lackorzynski, Jork Löser, Lars Reuther, Jens Syckor, and Carsten Weinhold.

Aim and goals of L4VFS

L4VFS was created with two problems in mind:

• DROPS mostly addressed servers and not objects. Object access was relatively specific for each server. We wanted to unify object addressing in a consistent way. A first step toward this goal is the definition and implementation of name spaces.

• A higher level of basic services than those provided by L4Env is required. Previously everybody was reinventing the wheel (e.g., file access) for his projects, especially if it included porting (parts of) POSIX-like applications to DROPS.

Main goal of L4VFS is to support porting of POSIX applications to L4 with a minimum of necessary changes by simply providing all the commonly used POSIX interfaces. Consequently, the L4VFS name space and the APIs resemble Unix concepts. However, L4VFS is not aiming for a complete implementation of the Single Unix Specification or a multi-server operating system with similar functionality. We focus on making the life easier for application developers on L4.

Architecture

As mentioned in the introduction, L4VFS comprises a set of client-side libraries, for instance for file descriptor handling, for managing mmaped regions, for routing time request to external time servers and so on.

Basically these servers provide the functionality classically provided by a monolithic operating system kernel. One particularly important server in our system is the name_server, which acts as the root name space provider and which coordinates all steps of name resolutions. In the figure below, you can see one such global name space depicted. Altogether there are three name spaces in the figure, which are all mounted together, for each node the volume_id and the local object_id are show. Note that not all objects in the figure are actually visible in the global name space (i, j, k, l) due to hiding behind the mount points c and f.

By clicking here (in the Demo-CD version of this document) you can start an interactive file system browser for this demo setup. You can explore the name space of the currently running demo setup by expanding the directory nodes. In this setup there are three interesting servers running:

• The vc_server (mounted to /server/vc) provides virtual consoles, which are discussed on the next pages,

• The simple_file_server (mounted to /server/sfs) provides static read-only files for small setups such as this, and

• The l4vfs_log server (mounted to /server/log) is a proxy server for the l4log server. It basically multiplexes write() calls to STDOUT on the log servers. Currently there should be one file in /servers/log (L4VFStree) which is used as STDOUT for the file system browser. Other programs could use terminals managed by the vc_server for their input and output.

You might wonder why we need several ways for processing STDOUT. In multi-server systems with many small components, some components are responsible for providing low-level services, such as memory management and interrupt handling and some provide higher level services, such as file systems. But also the lower layers need a means of communicating internal state, debug messages and so on. Therefore we have a layered architecture, which "bootstraps" higher services on-top of lower services.

Usage Scenarios

As L4VFS is mostly infrastructure work. Therefore, we will demonstrate its capabilities by discussing some usage scenarios in the following. The next page introduces text consoles and demonstrates escape sequence handling. We also show how to use a minimally modified GNU Readline Library for comfortable input handling. Not in this demo setup but on this demo CD you can find information about a Qt/Embedded port to DROPS based on L4VFS. Furthermore, Alexander Böttcher ported the Kaffe Java virtual machine to DROPS utilizing L4VFS as backend (not on this demo CD).

Text consoles

Text output to a console is a basic demand for application development. The terminal servers, term_con and vc_server, provide text consoles for the L4 Console and the DOpE window manager respectively. The later one is running in this demo setup.

Basically the terminal server provides a terminal namespace through the name_server. Client applications can then open the console files and issue read() and write() commands to them. With the help of the C library, this enables client applications to printf() data to the console and scanf() data that is input to this console. In this demo, the terminal files can be found in /server/vc/ and are called vc0 to vc3.

Please note, that for this demo, we limited the terminal server to four terminals, so if you open many programs at the same time they will share terminals. We also limited the amount of programs to start to around 30.

Escape sequences

Typically, contemporary terminal emulators (e.g., xterm) provide even more functionality than simply displaying and inserting text. They also have features to handle different text colors, place the cursor at a certain position inside the console, divide the screen into several scroll areas and much more. These features are used by writing certain strings to the console file. These strings start with the special character ESC (\\033) and are therefore called escape sequences.

The L4 term servers come with a VT100 library that is able to parse most of the escape sequences specified by the VT100 specification, as well as many others that are specified by VT220 and higher. The functioning of this library can be tested by running some VT100 art movies that extensively make use of these escape sequences.

You can view such movies, by opening /server/sfs/ in the file system browser and clicking on one of the VT files there. This will open a new terminal and show the movie in it. Press Return to close the terminal afterward.

Advanced line editing

The terminal servers provide basic input and output capabilities for a text console. Real console applications support even more features, like a line editing facility that lets you navigate through the currently edited line and delete or replace complete words or the whole line. Input-intensive applications furthermore can be improved with a history of recently entered commands and the possibility to search through this history.

Such features are provided by the GNU Readline Library on Linux. DROPS contains a port of this library with most features enabled. You can run an example application using libreadline by clicking here (in the Demo-CD version of this document). This application provides a user interface to the scripting language that drives the DOpE window manager.

For an overview of supported readline features, use the help command. You can access information on the DOpE scripting language by clicking on the DOpE User's guide in /servers/sfs/.

Outlook

We are currently working on several extensions to L4VFS, including a shell and exporting L4Linux file systems to L4VFS. Otherwise, we extend L4VFS on demand.

Contact

Martin Pohlack

 Technische Universität Dresden
 Fakultät Informatik
 Institut für Systemarchitektur (SyA)
 01062 Dresden

 pohlack@os.inf.tu-dresden.de

Björn Döbel

 Technische Universität Dresden
 Fakultät Informatik
 Institut für Systemarchitektur (SyA)
 01062 Dresden

 doebel@os.inf.tu-dresden.de

References

DROPS — The Dresden Real-Time Operating System

http://os.inf.tu-dresden.de/drops/

L4Linux

http://os.inf.tu-dresden.de/L4/LinuxOnL4/

Kaffe on DROPS

Alexander Böttcher, Integration of the Real-Time Specification for Java in L4 Kaffe. Master's Thesis. TU Dresden (10.06.2005) http://os.inf.tu-dresden.de/papers_ps/boettcher-diplom.pdf

diet libc

http://www.fefe.de/dietlibc/

uCLibc

http://www.uclibc.org/

GNU Readline Library

http://cnswww.cns.cwru.edu/~chet/readline/rltop.html

The Linux kernel

http://www.kernel.org/

Kaffe

http://www.kaffe.org/

VT100 Animations

http://artscene.textfiles.com/vt100/

Reboot the machine

Click here (in the Demo-CD version of this document) to reboot your machine.