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
On Sunday 12. August 2018 22.26.26 Paul Boddie wrote:
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.
I guess nobody had anything to say about this, which kind of suggests that a lot of the focus around L4Re is in virtualising Linux and arguably not playing to the strengths of the microkernel architecture. However...
[...]
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.
What I did find was some more information about the Spring operating system developed by Sun Labs back in the early 1990s. Helpfully, someone had written up a summary of various papers in the Wikipedia article in question (also doing so in an era when edits were not policed in a pedantic and draconian fashion, so the article remains rather informative), and with references to L4-based systems, it was hard to ignore:
https://en.wikipedia.org/wiki/Spring_(operating_system)
Reading a bit more about Spring in the research papers, there are some similarities with L4Re that suggest that some inspiration has been taken from the various things Spring implemented or provided. For instance, much is made of the naming service in Spring, and I cannot help feeling that the role of namespaces in L4Re is inspired by it.
It appears that Spring was discontinued in favour of enhancing Solaris (which those around at the time will remember was rather struggling to gain the confidence of established SunOS users, at least from the perspective of people I knew), and a Solaris-based cluster-oriented product was introduced employing various concepts and mechanisms from Spring. For instance, Spring's interface descriptions evolved into CORBA IDL which then became the basis of abstracting functionality in the multi-machine Solaris environment.
Anyway, since my last message I have been plugging away at writing L4Re components, even revisiting the use of interface descriptions and making a tool to generate code from them, so I thought I would share the above findings in case they jog anyone's memory or allow anyone to clarify what their objectives were with systems like TUDOS and other ostensibly general-purpose computing environments based on L4Re and its predecessors.
Paul
l4-hackers@os.inf.tu-dresden.de