Filesystem Architectures with L4Re and L4-Based Systems

[Paul Boddie]

Hello,

As this list can attest, I previously spent a bit of time diving into the way 
dynamic linking is supported by L4Re to get shared mode programs working. This 
turned out to have a relatively simple fix related to symbols employed by GCC-
generated code.

But during this exercise, I gained some familiarity with the way libraries are 
loaded, and this appears to involve the virtual filesystem support, with the 
loader perusing the filesystem to access libraries, and with these being 
provided as modules by the "rom" filesystem.

Since then, I've spent some time looking at how files are provided by 
filesystems and accessed by code that uses the conventional C or POSIX library 
interfaces. It raises a few questions about why things are done in a 
particular way in L4Re, and which approaches are in use for other L4-based 
systems, especially those that seek to provide general-purpose, multi-user 
solutions.

What I think I now understand about the virtual filesystem support in L4Re is 
as follows. The virtual filesystem itself is a "client-side" construct, 
meaning that it resides within any given program. That programs have their own 
view of a filesystem is not too different from what the documentation about 
systems like the Hurd describes and advocates, and I suppose it is a tempting 
approach because it gives each program the flexibility to be customised in 
this regard.

However, it seems that beyond the internal "mount tree" representation, 
configuration of the namespace hierarchy is largely done using the L4Re 
namespace concept, with namespaces acting as directories, and non-namespace 
objects within the hierarchy interpreted as particular file types. Apart from 
the interpretation of namespaces as directories, it seems that for the most 
part, dataspaces are employed to be interpreted as file objects.

I will admit that I didn't really look very hard at how different systems 
provide file access before now, but what surprised me slightly was the 
apparent lack of delegation in L4Re. As far as I can tell, on systems based on 
kernels like Linux, the open library function will employ a system call to 
delegate the matter of finding the file and obtaining a way of accessing it to 
the familiar monolithic-kernel-plus-filesystems arrangement.

On more "exotic" systems (than Linux) like Minix 3 or the Hurd, it appears 
that delegation to a virtual filesystem server [1] or servers [2] occurs to 
mediate access to specific files. Some systems like Inferno and Plan 9 employ 
protocols [3] to formalise the client-server relationship. I had almost 
expected to find similar things in L4Re, but I could only confirm their 
absence after reviewing the various VFS abstractions.

One thing I wonder about is whether the current L4Re approach is able to 
satisfactorily deal with filesystem content that needs to serve different user 
entities, with content having different permission and ownership rights. It 
seems that the filesystem logic has to be available as a library within a 
program, which is not necessarily a problem.

But to avoid filesystem content being completely exposed to the discretion of 
user programs (reminiscent of the problems with early Network File System 
implementations), the library would need to call out to other entities, which 
doesn't appear to be done with the current L4Re abstractions. One could 
implement support for, say, the ext3 filesystem in a library, operating on a 
dataspace provided at some kind of mountpoint in a directory (with the 
directory being provided by a namespace, of course) but it would be like 
giving a user program access to a block device in a traditional Unix-like 
system.

Are there any articles about the design of L4Re that might explain the 
motivations here? And are there any accessible-but-detailed articles about 
other microkernel-based systems and the way in which they structure their 
filesystem architectures? I looked around on the TU-Dresden site for 
materials, but I didn't immediately find anything obviously relevant.

Paul

[1] https://wiki.minix3.org/doku.php?id=developersguide:vfsinternals
[2] https://www.gnu.org/software/hurd/hurd-talk.html#pat
[3] http://doc.cat-v.org/inferno/4th_edition/styx