The design of mdev (mini-udev for busybox).
pgf at brightstareng.com
Mon Dec 5 23:26:22 UTC 2005
> > 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 fox, pgf at brightstareng.com
More information about the busybox