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

[Paul Fox]

 > > 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:

ah cool.  thanks.

 > >
 > >  > 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 

yes -- inittar use the builtin gzip, but an add-on bunzip2.

 > > 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 

ah.  good again.

 > > 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.

for our product purposes, we want the flexibility (i didn't say we're
doing it yet :-) to actually do this in the field -- pull a kernel/root
combo out of flash, pull off the tarball, add more tarball to it, and
reflash.  currently i can do that with pretty minimal tools.  i'd
rather not need make or a linker.  :-)

 > > 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.

i see.  i think i got that impression from your doc page:
    "Note that those two example "file" entries expect to find
    files named "init.sh" and "busybox" in a directory called
    "initramfs", under the linux-2.6.* directory."
presumably i should have followed the pointer in the next sentence
to get the complete answer.  :-)

 > > 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

plus the need for a linker to rebuild.  and 2.4 kernel support.  other
than that, you're right -- they're identical.  ;-)

anyway, now i'm truly enlightened.

now let's get back to busybox...

paul
=---------------------
 paul fox, pgf at brightstareng.com