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

Paul Fox pgf at
Mon Dec 5 20:27:58 UTC 2005

hi rob -- thanks for the detailed response.

 > > can someone tell me why cpio was chosen for this?  wouldn't tar be
 > > just as useful, and lower cost in "oh-no-not-another-required-tool" terms?
 > The actual flame war (in december, 2001) started here:
 > And spawned a second thread (specifically on tar vs cpio) here:
 > I'd definitely recommend reading all of both threads.

thanks.  no emotions there, eh?  :-)

 > 1) The cpio format is simpler for the kernel to parse.  Internally, tar is a 
 > bit of a hack with gnu extensions and such.

i'll take your word for it.  i haven't looked at the kernel's
cpio parser.  the inittar.c from the page i referenced isn't
exactly rocket science, but i can certainly imagine simpler code.

 > 2) cpio actually predates tar, it's been part of unix from the AT&T days...

oh, i certainly knew that.  20 years ago (5 years after starting
to work at AT&T) i used to think "why the hell did they invent
tar?  cpio is perfectly adequate."  and i still move directories
using cpio sometimes.  but now the number of people and tools
that can deal with the two formats is clearly weighted to tar.

 > So saying "oh no, not another tool!" is kinda silly since this predates System 
 > V and any system that uses RPM is likely to have cpio installed on general 
 > principles.  You just never noticed.  (By the way, Red Hat also uses cpio for 
sure, it's not big thing, but every time you add a tool to a build
system you add something else that needs to be cataloged, packaged,
documented, understood by all the developers, etc.  it's not like
it's zero overhead.  but i take your point.

 > > having no more need for creating an initrd is nice at build time
 > > (no need to be root), and at runtime: instead of setting up an 
 > > initrd, and then needing tmpfs in addition, the tarball goes
 > > right into tmpfs, which gets mounted directly as root.
 > Did you read my initramfs documentation?

i hadn't seen that -- thanks for the pointer.

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

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

 > > i realize initramfs solves a slightly different problem than this,
 > Not really.  You're re-inventing the wheel.  The text file format 

well, i don't think the inittar patches are _completely_
re-inventing the wheel (they're not mine, btw -- sorry if i gave
that impression.  we're using them, and have contributed a couple
of fixes, but i take no credit).  (and please read to the end
before rebutting -- i'm not trying to dis initramfs.  :-)

for one, inittar works with 2.4 kernels -- initramfs is 2.6-only? 
second, the root filesystem created is in a tmpfs, which as you
know is a somewhat different beast than a ramfs.  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.

third, the tar archive isn't built-in to the kernel -- it's glued
on, like an initrd.  i can build a single bare kernel, and
separately build several root filesystems for it (as tarballs),
and glue them together with mkimage on an as-needed basis.  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. 
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?  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.

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.

anyway, thanks for the education on initramfs.

 paul fox, pgf at

More information about the busybox mailing list