L4VFS - L4 virtual file system layer
Martin Pohlack and Björn Döbel
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.,
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
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.
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 (
l) due to
hiding behind the mount points
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
vc_server (mounted to
/server/vc) provides virtual consoles,
which are discussed on the next pages,
simple_file_server (mounted to
/server/sfs) provides static
read-only files for small setups such as this, and
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
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.
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 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
write() commands to them. With the help of the C
library, this enables client applications to
printf() data to the
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.
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
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
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
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
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.
- Martin Pohlack
Technische Universität Dresden
Institut für Systemarchitektur (SyA)
- Björn Döbel
Technische Universität Dresden
Institut für Systemarchitektur (SyA)
- DROPS — The Dresden Real-Time Operating System
- 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)
- diet libc
- GNU Readline Library
- The Linux kernel
- VT100 Animations
Reboot the machine
Click here (in the Demo-CD version of this document) to reboot your machine.