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]
HI, I'm looking for the information and procedure how to compile and deploy L4Re on Raspberry PI. Any feedbacks would be greatly appreciated! Thanks, Lei
Hi Adam & Hackers,
Has anybody enabled network access for L4linux Raspberry pi3? I read through all the history on related topics and understand the process to get it working. I summarized the steps as below and major problem for me is how to convert device tree for L4linux and compose corresponding rpi_deices.io configuration. Please see my specific question inlined in those steps. Thanks in advance for your feedback.
1. configure and Compile l4linux to support flattened …
[View More]device tree support. Also enables
CONFIG_USB_LAN78XX=y &&
CONFIG_USB_USBNET=y
CONFIG_USB_NET_SMSC95XX=y
CONFIG_L4_SERVER = y
CONFIG_USE_OF = y
2. Adapt https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2… into ./l4linux/arch/l4/boot/dts/simple.dts
[Lei's question]: I understand why bcm2710-rpi-3-b.dts cannot be used directly because some of the reg_address physical address doesn't apply and might fail to be mapped. How can I pick network access specific device nodes and its dependancies(power or clock etc) and how to change those illegal reg_address?
3. Create an rpi3_devices.io for L4Re with the devices and their resources and assign the desired devices to a vbus.
[Lei's question]: Should I define all device nodes one-2-one mapping from step 2's device tree?
4. Update your ned script and modules.list
-- vim:set ft=lua:
local L4 = require("L4");
loader = L4.default_loader;
-- Start io
vbus_l4linux = loader:new_channel();
--vbus_input = loader:new_channel();
--vbus_fbdrv = loader:new_channel();
loader:start(
{
caps = {
sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0);
icu = L4.Env.icu;
-- input = vbus_input:svr();
l4linux = vbus_l4linux:svr();
-- fbdrv = vbus_fbdrv:svr();
},
log = {"IO", "y"},
l4re_dbg = L4.Dbg.Warn,
}, "rom/io -vvv rom/rpi_devices.io");
-- Start L4linux
loader:start(
{
caps = {
-- fb = mag_svc:create(L4.Proto.Goos, "g=640x480");
vbus = vbus_l4linux;
},
log = L4.Env.log:m("rws"),
l4re_dbg = L4.Dbg.Warn,
},
"rom/vmlinuz mem=64M console=ttyLv0 l4x_rd=rom/ramdisk- l4x_dtb=rom/rpi3b-simple.dtb"
.. L4.Info.arch() .. ".rd " ..
"root=1:0 ramdisk_size=4000 init=/bin/sh earlyprintk=1 ");
5. Build final bootstrap_l4linux.uimage for Raspberry.
Thanks very much!
Lei Zhou
[View Less]
After I brought up L4Re and Fiasco on Raspberry PI3, would like to enable guest Linux VM on top of it.
I'm looking at the link https://github.com/kernkonzept/manifest/wiki/LinuxVM and hoping I can do the same thing on Raspberry PI3.
The link seems using hardware-assisted virtualization option uvmm based for guest VM. There seems also L4Linux Paravirtualization option. Which option should I use for me to enable guest LInux VM on Raspberry PI3?
In addition, when I followed the …
[View More]link to try on QEMU first, encounter some "vbus" capability issue. I followed the guidance exactly as the link says. However, when I started the command to spawning the Linux VM as:
$make E=uvmm-basic qemu
It failed with following log:
============================================
MOE: virtual user address space [0-7fffffffff]
MOE: rom name space cap -> [C:103000]
MOE: rwfs name space cap -> [C:105000]
BOOTFS: [41100000-411974b8] [C:107000] uvmm
BOOTFS: [41198000-411c4e58] [C:109000] l4re
BOOTFS: [411c5000-41246770] [C:10b000] ned
BOOTFS: [41247000-412475c4] [C:10d000] virt-arm_virt.dtb
BOOTFS: [41248000-41430200] [C:10f000] ramdisk-armv8.cpio.gz
BOOTFS: [41431000-41431242] [C:111000] uvmm-basic.ned
BOOTFS: [41432000-42618a00] [C:113000] Image.gz
MOE: cmdline: moe rom/uvmm-basic.ned
MOE: Starting: rom/ned rom/uvmm-basic.ned
MOE: loading 'rom/ned'
Ned says: Hi World!
Ned: loading file: 'rom/uvmm-basic.ned'
VMM[vmbus]: 'vbus' capability not found. Hardware access not possible for VM.
VMM[main]: Hello out there.
VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the virtual GICC via the vbus
VMM[vm]: Device creation for virtual device virtio_uart@20000 failed. Disabling device.
VMM[]: virtio_net(a)10000.l4vmm,virtiocap: capability net is invalid.
VMM[vm]: Device creation for virtual device virtio_net@10000 failed. Disabling device.
VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the virtual GICC via the vbus
VMM[vm]: Device creation for virtual device interrupt-controller failed. Disabling device.
VMM: FATAL: Parsing timer interrupt: Argument out of range
qemu-system-aarch64: terminating on signal 2
Makefile:6: recipe for target 'do-all-make-goals' failed
make: *** [do-all-make-goals] Interrupt
=========================================================================
Any feedbacks are greatly appreciated!
Lei Zhou
[View Less]
Hello,
In attempting to investigate building L4Re/Fiasco.OC for the Raspberry Pi
Zero, I encountered an unusual problem: unusual because, I suppose, most
people do not try and cross-build on architectures other than x86(-64).
When performing the initial L4Re build directory initialisation step...
make B=mybuild
...BUILD_ARCH seems to be set to x86 even on other architectures. This then
causes CCXX_FLAGS to be populated with x86-dependent settings such as -m32,
and the gcc host compilers …
[View More]for MIPS raise errors upon encountering these
unrecognised arguments.
Here is the offending command in the top-level Makefile (line 376 in my
version, r83 in Subversion):
GENDEP_OUTPUT=$$X.out $(CC) $(CCXX_FLAGS) -c $$X -o $$X.o
Although it seemed like the config step could be performed after ignoring
these errors, I did wonder if there might be some undesirable consequences. In
the end, I found that the following invocation was needed:
make B=mybuild CC=gcc CXX=g++ LD=ld BUILD_ARCH=mips CPU=32r2 CPU_ABI=32
After that, things seem to work as expected. I imagine that there is a
"chicken and egg" situation here: the appropriate settings would be obtained
from the configuration, but the command being run sets up the configuration.
Has anyone else seen this problem before?
Paul
[View Less]