LWN: Comments on "Initramfs arrives"

Initrd Dynamic

pkern — Sun, 15 Jan 2006 15:17:49 +0000

Old threads die hard...

`ar' is indeed the outer container for a Debian package, but all files and control data inside of it is stored in tar.{gz,bz2}.

Tar vs. cpio

EricBackus — Fri, 15 Nov 2002 00:43:58 +0000

Actually, the cpio command-line interface appears cleaner to me than tar's. But that's not enough reason to use cpio.

Both tar and cpio provide similar capabilities and store similar information about the files they contain. However, tar is *far* more commonly used than cpio, which means that tar extraction programs are also far more available than cpio. Furthermore, in spite of the older variations on the tar format, there has for some years been a standard for it.

I'm not convinced that cpio is really "saner" than the standard tar format, but even if that's true, we have known-good code for dealing with tar archives (GNU tar, and probably half a dozen independent implementations).

Tar is the de facto standard, and "standard is better than better".

Initramfs arrives

IkeTo — Tue, 12 Nov 2002 15:09:25 +0000

Perhaps the section in Kernel Traffic about the matter can give some idea about what it is about. Or perhaps just its name gives enough idea what it is: "Early user-space".

If my understanding is correct (correct me if not), the problem is that traditionally, the first user-mode code can be executed only when the init process (process 1) is created by the swapper process (process 0), which is quite some time after the computer boots up. Further, process 1 requires a complete user-mode picture, so at that time a lot of things must have been set up correctly. Things like a working root directory or a working initrd image, a working console (together with fonts), etc. All these must be hard-coded in kernel mode, even though the code to do such things as mounting a root directory, choose a console driver, etc., must be exposed to the userland anyway for later manipulations.

So the idea is that a "sorta user space" is created, which executes without the full privilege of the kernel just like a "real" user-space, and interacts with the kernel using system calls likewise, but is non-compliant to any Unix standard, and can lack anything that a normal user-space program would normally expect: things like user-id, root directory (or even a real directory structure), console driver, C-library, process id, etc can all be missing. By removing the full user-space burden, we can execute user-space "mini-programs" to do the initialization tasks that are currently done by hard-coding into kernel. The advantage is that the amount of code to be executed in kernel mode is reduced. The remaining of the story is that of the LWN article.

So the initrd mechanism handles the loading of modules, but that's it. Still the kernel has to mount of the root directory (which is the initrd directory), and this has to be hard-coded. It does remove the pain of having to recompile the kernel everytime (because now the hard-coding is only for things that *can* be made always the same), but still the kernel bloat is there. Early user-space take them out.

Initrd Dynamic

IkeTo — Tue, 12 Nov 2002 14:25:56 +0000

Debian format isn't based on tar (or tar.gz, or tar.bz2) at all! See deb(5). It is based on ar. Of course, in source package, you need to patch the original of some package, and that original can be of any form, be it tar.gz, or tar.bz2, or even rpm. But the deb format is not based on them.

Initrd Dynamic

Peter — Fri, 08 Nov 2002 22:09:47 +0000

(note: I like tar better than cpio as well).

You probably mean you like the /usr/bin/tar interface better than the /usr/bin/cpio interface. Hey, who doesn't? `tar' is quite confusing when you first try to figure out the command line, but we've all long since learned the important options. But there's a reason Red Hat picked cpio as the basis for the RPM package format. As people have said on linux-kernel, tar is a mess of a format, compatibility-wise - the original version had some annoying filename length limitations and stored only numeric uid/gids, and there are two or three derivative formats that remove these limitations but as kludges so as not to completely confuse old `tar' programs. I understand cpio is a much saner format, from an implementor's point of view. That's why Al Viro and co. went with it for initramfs.

(Interestingly, although RPM is based on cpio, Debian's .deb format is based on tar.gz or, recently, tar.bz2.)

Initrd Dynamic

pflugstad — Thu, 07 Nov 2002 15:53:53 +0000

And just to confusing things, Dave Cinege posts a new Initrd

http://lwn.net/Articles/14394/

which supposed does many of the same things as initramfs.
(note: I like tar better than cpio as well).

Pete

Initramfs arrives

dougm — Thu, 07 Nov 2002 15:47:50 +0000

"RAM-based disk" is an unfortunate term--ramfs is not based on a block device at all--it's just a tree of dentries/inodes in memory, so there's nothing in there that looks like a disk. It's significantly simpler and more space-efficient than a ramdisk, since you're not duplicating data between the RD block device and the dentry and inode caches. I see it as conceptually cleaner as well, since you don't have to have any particular filesystem drivers loaded when early userspace starts up...

Initramfs arrives

pflugstad — Thu, 07 Nov 2002 15:39:26 +0000

I agree with eru - I think a bit more explanation is needed here
as well.

Also, I recall there was some discussion about moving *all* the
modules to this initramfs as well: you would not have any modules
at all anymore, but all drivers would be modules, but they'd be
explicitly built into the kernel. Or am I dreaming again :-).

Initramfs arrives, why?

eru — Thu, 07 Nov 2002 11:59:59 +0000

Now I am puzzled. I always thought the "initrd" mechanism was intended
precisely for the kinds of things that are now supposed to be handled
by "initramfs". Either of these seems redundant to me.
What is there that use-space code in "initramfs" can do that
it could not do on "initrd" ?