The design of mdev (mini-udev for busybox).

[Rob Landley]

On Monday 05 December 2005 14:27, Paul Fox wrote:

>  > I'd definitely recommend reading all of both threads.
>
> thanks.  no emotions there, eh?  :-)

Al Viro was involved.  Nuff said. :)

>  > Did you read my initramfs documentation?
>  > http://sosdg.org/~coywolf/lxr/source/Documentation/filesystems/ramfs-roo
>  >tfs-initramfs.txt
>
> i hadn't seen that -- thanks for the pointer.

Since you're something like the fifth person to bring this up since I wrote 
that, I just added a section to it:

http://seclists.org/lists/linux-kernel/2005/Dec/1146.html

>  > You don't need to be root for the kernel to build a cpio archive for you
>  > during the kernel build.
>
> yes, i knew that.  i was comparing the need for root access against
> the previous initrd mechanism, where one usually had to create a real
> filesystem on a loopback mount in order to create the initrd image.
> (yes, yes, i know:  qemu is cool, and solves this problem.  :-)

I use User Mode Linux myself, both because qemu is an external package 
dependency and because with UML you don't need to make a root filesystem.  
Just build in hostfs and then borrow the parent's filesystem:

The miniconfig:

CONFIG_MODE_SKAS=y
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_SWAP=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_FUTEX=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SHMEM=y
CONFIG_LBD=y
CONFIG_STDERR_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_BLK_DEV_UBD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_EXT2_FS=y
CONFIG_DNOTIFY=y
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y

The command line:

./linux rootfstype=hostfs rw init=/bin/sh

>  > In fact you don't even need cpio installed on the
>  > system.
>
> this i didn't know.
>
>  > So your external patch's entire reason for existing is because you want
>  > to use a different format for the kernel's internal data storage.  (Out
>  > of curiosity, is there a patch for using "zip"?)
>
> no -- just tar, optionally gzipped or bzipp2ed.

gzip is built into the kernel.  I offered my bunzip2 patch to the linux kernel 
guys but unfortunately I'd have to modify the make file to make it work, and 
you know how I am with makefiles...

Besides, the current winner is lzma.  (Which we _really_ should add to busybox 
in 1.2.)

> for one, inittar works with 2.4 kernels -- initramfs is 2.6-only?

Point.

> second, the root filesystem created is in a tmpfs, which as you
> know is a somewhat different beast than a ramfs.

I'm under the vague impression that rootfs can be tmpfs, but perhaps that's 
still an external patch.  (A patch for this was submitted back in August.  I 
don't remember if it was merged or not, I haven't looked...)

> once our 
> embedded system is booted with the tmpfs-mounted root that came
> from the tarball, that's it.  no remounting, no pivot-rooting, no
> extra /tmp filesystem to mount.  i like simple.

Yup, lots of people do that with the cpio initramfs.

> third, the tar archive isn't built-in to the kernel -- it's glued
> on, like an initrd.

I consider that a downside, but I'd like to point out that you still have the 
option to do that with initramfs.  If you build in initrd support but feed it 
an initramfs image, it'll autodetect the type.  (I remember this from reading 
the code, I' haven't actually tried it...)

> if
> i've already glued them together, i can even unglue them, add to
> the tarball (since tarballs are essentially cat'table) and reglue
> it, allowing different combinations of root files pretty simply.

Working out how to do this for initramfs has been on my todo list for a while.  
Unfortunately, it involves tracing through the kernel's makefiles to see 
where the TMPPIGGY part is.  (See "me and makefiles", above.  It's not that I 
can't do it, it just doesn't bubble to the top of my todo list unless it's 
blocking something else I want/need to do...) 

> very easy to deal with from a packaging and scripting
> perspective.  if initramfs is always populated as part of a
> kernel build, it makes it hard to swap roots, doesn't it?

Not really.  What I did is build the kernel, then swap out the initramfs.txt 
target and rebuild.  It doesn't have to recompile everything, just regenerate 
the cpio archive and re-link.  Thus for my firmware system, I can make the 
installer executable and the firmware executable from the same User Mode 
Linux compile.

> and 
> requiring the members of the elements of the initial filesystem
> to all live under the kernel source directory (is that necessary
> if you want to use gen_init_cpio?) seems a bit restrictive.

It doesn't, that's just where I put it.  You can point CONFIG_INITRAMFS_SOURCE 
to anything.  Feed it an absolute path, etc.

By the way, if you build out of tree (O=../blah) then the default directory 
it'll look for this stuff in will be the _build_ directory, not the source 
directory.  (You can fix that with a symlink if it's not what you want.)

> all this is why it feels like the two mechanisms are solving
> somewhat different problems.  but remember, i'm mostly comparing
> to initrd-based systems, which is what we (like most others) were
> doing before we found the inittar patches -- initramfs may be
> useable in some of these ways as well.  i'm just ignorant of it.

Initramfs is very different from initrd, and it sounds like the only thing it 
doesn't already do that you want is the TMPFS mount for rootfs.  (And I was 
pretty sure that had already been merged, I'm just not finding the config 
option for it right now...)

Possibly if you select CONFIG_TMPFS then rootfs will automatically be tmpfs, 
and thus there's no separate config option.  That sounds familiar.  (Doesn't 
mean it's _right_...)

> anyway, thanks for the education on initramfs.

Glad I could help. :)

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.