Initramfs arrives

The "initramfs" concept has been in the 2.5 plans since back before there was a 2.5 kernel. Things have been very quiet on the initramfs front, however, until the first patch showed up and was merged into the 2.5.46 tree.

The basic idea behind initramfs is that a cpio archive can be attached to the kernel image itself. At boot time, the kernel unpacks that archive into a RAM-based disk, which is then mounted and used at the initial root filesystem. Much of the kernel initialization and bootstrap code can then be moved into this disk and run in user mode. Tasks like finding the real root disk, boot-time networking setup, handling of initrd-style ramdisks, ACPI setup, etc. will be shifted out of the kernel in this way.

An obvious advantage of this scheme is that the size of the kernel code itself can shrink. That does not free memory for a running system, since the Linux kernel already dumps initialization code when it is no longer needed. But a smaller code base for the kernel itself makes the whole thing a little easier to maintain, and that is always a good thing. But the real advantages of initramfs are:

• Customizing the early boot process becomes much easier. Anybody who needs to change how the system boot can now do so with user-space code; patching the kernel itself will no longer be required.

• Moving the initialization code into user space makes it easier to write that code - it has a full C library, memory protection, etc.

• As pointed out by Alexander Viro: user-space code is required to deal with the kernel via system calls. This requirement will flush a lot of in-kernel "magic" currently used by the initialization code; the result will be cleaner, safer code.

The patch, as found in 2.5.46, does not do a whole lot; it adds the basic mechanism but only removes "three simple lines" from the current initialization code. The bulk of the code will be added in the coming weeks - now that the "feature" is in the kernel, the details can be filled in without, technically, breaking the feature freeze. The plan for those steps has been laid out by Jeff Garzik:

• A small C library ("klibc") will be merged to support initramfs applications.

• A small "kinit" application will be created with klibc. In the beginning, it will only do enough work to show that the mechanism is functioning properly.

• The "initrd" (initial ramdisk) subsystem will be moved into kinit, and out of the kernel itself.

• The mounting of the root filesystem will be moved to user space. A lot of code for dealing with things like NFS-mounted root filesystems will go away.

That is as far as the plan goes, for now. There is no doubt that other parts of the initialization process will be moved to user space, however; it will be interesting to see how that process goes.

There a couple of fundamental open questions that will have to be answered during the remaining 2.5 development period. One is whether the initialization process should be handled by a single "kinit" application, or whether it should be a collection of programs, and, probably, shell scripts. Then, there is the question of what to do with klibc. It will be packaged with the kernel for now, but a number of kernel developers think that klibc (and the whole user-space initialization setup) should eventually be split off into a separate project. These decisions might not be made until very shortly before the stable release.

Index entries for this article
Kernel	initramfs

---

to post comments

Initramfs arrives, why?

Posted Nov 7, 2002 11:59 UTC (Thu) by eru (subscriber, #2753) [Link]

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

Initramfs arrives

Posted Nov 7, 2002 15:39 UTC (Thu) by pflugstad (subscriber, #224) [Link] (1 responses)

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

Posted Nov 12, 2002 15:09 UTC (Tue) by IkeTo (subscriber, #2122) [Link]

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.

Initramfs arrives

Posted Nov 7, 2002 15:47 UTC (Thu) by dougm (guest, #4615) [Link]

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

Initrd Dynamic

Posted Nov 7, 2002 15:53 UTC (Thu) by pflugstad (subscriber, #224) [Link] (4 responses)

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

Initrd Dynamic

Posted Nov 8, 2002 22:09 UTC (Fri) by Peter (guest, #1127) [Link] (3 responses)

(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

Posted Nov 12, 2002 14:25 UTC (Tue) by IkeTo (subscriber, #2122) [Link] (1 responses)

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

Posted Jan 15, 2006 15:17 UTC (Sun) by pkern (subscriber, #32883) [Link]

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

Posted Nov 15, 2002 0:43 UTC (Fri) by EricBackus (guest, #2816) [Link]

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