looking for a model for building CRAMFS(?)-based system
Fillod Stephane
stephane.fillod at thomson.net
Fri Mar 18 03:17:36 EST 2005
Robert P. J. Day wrote:
> now this is the sticky part. imagine this system out in the field,
> where you need to make an update to something in the initrd in the
> root filesystem.
You could get away with mirrored partitions, having version N and N-1
in flash, so a rollback is possible. But static partitions suck,
they are either too big (space wasted), either too small (!!).
Here's an idea I'd enjoy having feedback from: why not dedicating
the whole flash to a jffs2 space, allowing a kind of "dynamic"
partitioning with the composing filesystems in image files accessed
trough
loop devices? For example, the base system (libc, busybox, startup
scripts, ..) would be packed as a cramfs/squashfs file, put in the jffs2
storage. This image file would be mounted as root fs in 2 steps through
a loop device, thanks to a small patch against linux/init/do_mounts.c.
I've named this idea "Initial loopback (initlo) support", patch's
available.
Choosing the rootfs image is done through kernel command line.
For example, let's say /dev/mtdblock0 is the jffs2 storage, and the real
rootfs is a cramfs image file "rev1/rootfs.img" (from base of
mtdblock0).
The command line would be:
root=/dev/mtdblock0 lofile=rev1/rootfs.img
After bootup, the rootfs.img is the rootfs /, and the mtdblock0 space
is pivoted to /initlo, hence still accessible.
It's easy to have whatever number of rootfs versions, switching from
one another, and updating the kernel command line only when install
succeeded (=no power fail,..).
During normal operation, the jffs2 storage is kept read-only for safety.
Only during install it is remounted read-write.
Applications can be packaged the same way (image file). jffs2 will be
happy
to store also configuration files/data and at least 2 kernel versions
(for
safe update). Great monitors like U-Boot are able to load the kernel
image
(and other firmwares) from jffs2. The jffs2 loader is portable.
Note: these filesystems in a filesystem look inefficient (read slow
startup),
but who cares, you're already relying on compression. Please note that
once
loaded in pagecache, the system runs at full speed. cramfs/squashfs are
at
advantage here over initrd, because only needed files make it into the
pagecache.
Comments welcome
--
Stephane
More information about the Linuxppc-embedded
mailing list