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
…
[View More]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
[View Less]
Hello,
I have been looking at trying out L4Linux in UX mode as a first step towards
its use on "native" Fiasco, and I seem to be experiencing a problem with
launching the Linux kernel itself.
I have followed the instructions from these pages:
https://l4linux.org/download.shtmlhttps://l4linux.org/build.shtmlhttps://l4linux.org/use.shtml
Specifically, I have an existing build of UX that has been used for some time
to develop software. I have updated it to revision 83 and have checked …
[View More]out the
l4linux_requirements, which appear to be some packages (rtc and shmc) I
already have. I then performed a build once again:
make O=mybuild
The L4Linux repository has also been checked out and updated to revision 83.
The code has been configured and built using the following invocations:
make O=mybuild x86_32-ux_defconfig
make O=mybuild menuconfig # to set the L4Re build directory
make O=mybuild
Here, the mybuild directory is distinct from the L4Re mybuild directory.
For the initial RAM filesystem, I downloaded the ramdisk-x86.rd file, and I
run the system as follows:
make O=mybuild ux E=L4Linux-basic
After the usual familiar start-up messages, I see this output specific to the
configuration being launched:
----
Ned: loading file: 'rom/l4lx.cfg'
libio: Warning: Query of 'vbus' failed!
PH 0 offs=00001000 flags=r-x PH-type=0x1
virt=00100000 evirt=0053f000
phys=00100000 ephys=0053f000
f_sz=0043f000 memsz=0043f000
PH 1 offs=00440000 flags=rw- PH-type=0x1
virt=0053f000 evirt=00a58000
phys=0053f000 ephys=00a58000
f_sz=0006ce9f memsz=00519000
PH 2 offs=00371ee0 flags=--- PH-type=0x4
virt=00470ee0 evirt=00470f1c
phys=00470ee0 ephys=00470f1c
f_sz=0000003c memsz=0000003c
Starting binary at 0x100000, argc=6 argv=0xafff4f84 *argv=0xb1007ff4
argv0=rom/vmlinuz
External resolver is at 0xa8000bd0
L4Re: rom/vmlinuz: Unhandled exception: PC=0x46980b PFA=97d47fe0 LdrFlgs=0
----
In order to try and identify the problem, I used the following command:
addr2line -e ~/L4/L4Linux/l4linux/mybuild/vmlinux 0x46980b
This seems to indicate that the point of failure is at line 2727 in
arch/l4/kernel/main.c which is the start of this function:
int __ref L4_CV main(int argc, char **argv)
So, I wonder what the problem might be that leads to a crash as the main
function is being invoked. Have I missed anything obvious?
All of this is being done in a Debian unstable chroot on x86.
Paul
[View Less]
