User space filesystems for L4Linux

[Uwe Geuder]

Hi!

When looking at the examples and forum archives I get the impression
that L4Linux users tend to work with ramdisks. However, in general I
understand that in the Linux world ramdisks are considered mostly
obsolete. Initramfs is the preferred solution

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/ramfs-rootfs-initramfs.txt?id=refs/tags/v3.14.12

I replaced my disk image with a cpio archive suitable for initramfs
and everything still works fine. Linux can dynamically recognize whether
it is cpio or not. I understand my filesystem can grow dynamically
until Linx runs out of memory. I dropped the ramdisk_size parameter
from the kernel command line. Are there any drawbacks or pitfalls I am
missing?

The next step is compression. Both ramdisks and cpio archives can be
compressed, again Linux can dynamically recognize that and uncompress
before usage. (I have only tested cpio.gz so far, but I understand
also disk images work and both faster lzo and more aggressive bzip2
and xz are supported.)

However, when I tried to used my cpio.gz archive, the effect was zero.
Someone had magically uncompressed my archive before making the U-Boot
image.  I tracked it down to the script
src/l4/pkg/bootstrap/server/src/build.pl.

> system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null");
> $file = "$modname.ugz" if !$?;

It unpacks everything that is gzip compressed. Maybe that is necessary
for object or executable files, I see some assembly manipulation a
couple of lines further down, which I have not analyzed. However, for
disk images or initramfs archives I cannot see the point.

So I made the following hack

diff --git a/src/l4/pkg/bootstrap/server/src/build.pl b/src/l4/pkg/bootstrap/server/src/build.pl
index 22382d6..a31743e 100755
--- a/src/l4/pkg/bootstrap/server/src/build.pl
+++ b/src/l4/pkg/bootstrap/server/src/build.pl
@@ -75,8 +75,13 @@ sub build_obj($$$)
   printf STDERR "Merging image %s to %s [%dkB]\n",
                 $file, $modname, ((-s $file) + 1023) / 1024;
   # make sure that the file isn't already compressed
-  system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null");
-  $file = "$modname.ugz" if !$?;
+  if ($file =~ m/ramdisk-arm.rd$/) {
+      system("false");
+  } else {
+      system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null");
+  }
+  $file = "$modname.ugz" if !$? ;
+  print "using ", $file ;
   system("$prog_objcopy -S $file $modname.obj 2> /dev/null")
     if $strip && !$no_strip;
   system("$prog_cp         $file $modname.obj")

This worked as expected, my disk image remained compressed and Linux
could uncompress it a boot time. Of course it is a hack, because
the file name should not be hard-coded there. Same question as before,
am I missing anything here?

Also build.pl would fail to do the uncompression if a module is
compressed with lzo, bzip2 or xz.

Yes, I have found the variable BOOTSTRAP_UIMAGE_COMPRESSION. It worked
fine during image creation, but during boot U-Boot failed with


>   Verifying Checksum ... OK
>   Uncompressing Kernel Image ... Error: inflate() returned -5
> GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover
> resetting ...

I assume this could be fixed by modiyfing the memory map. However,
because my kernel is very small compared to the user space image and
Linux has this nice dynamic support for various compression schemes I
think I prefer an uncompressed U-Boot image containing a compressed
user space image.

Regards,

Uwe Geuder
Nomovok Ltd.
Tampere, Finland
uwe.gxuder at nomovok.com (bot test: humans correct 1 obvious spelling error)