Linus, The attached below is the first of several changes for initramfs / early userspace. This change is intentionally very simple, not really proving its worth until next week when patches 2 and 3 in this series arrive in your inbox. A description of "the future" follows description of this specific cset. 1) Introduce init/initramfs.c itself, which is a module that uncompresses a .cpio.gz archive, and uses it to populate rootfs with files early very in the bootup process (between signals_init and proc_root_init in init/main.c). People will see a small listing in dmesg of unpacked files. We need to keep this for now (and for now it's small), but we may want to remove this output or turn the knob down to KERN_DEBUG before 2.6.x release: -> file1 -> file2 -> etc... (architecture maintainers note!) 2) Introduce ARCHBLOBLFLAGS in arch/$arch/Makefile, for turning an arbitrary binary object into a .o file using objcopy. 3) Link the initramfs cpio archive in vmlinux image via arch/$arch/vmlinux.lds.S, in the init section. 4) Introduce the new linux/usr directory. Currently it is not very interesting, only containing a small host-built proggie that generates the initial cpio archive, gen_init_cpio. This program will go away when early userspace is further along. It currently exists to show initramfs is working, by allowing us to remove three simple lines from init/do_mounts.c. The Future. Early userspace is going to be merged in a series of evolutionary changes, following what I call "The Al Viro model." NO KERNEL BEHAVIOR SHOULD CHANGE. [that's for the lkml listeners, not you ] "make" will continue to simply Do The Right Thing(tm) on all platforms, while the kernel image continues to get progressively smaller. Here is the initial plan for early userspace, i.e. the patches you are going to be seeing next week: #2 - merge klibc. As I said earlier, I am not sure if we will wind up removing klibc just before 2.6.x release or not. Comments welcome. But for now, klibc will be merged into the kernel tarball, because otherwise version drift during the evolution of early userspace will be a huge PITA, and slow things down. It is a tiny libc written specifically for the kernel. This patch will add klibc to the build system, and create a tiny, statically-linked binary "kinit". kinit is the beginnings of early userspace. Some tiny, token amount of do_mounts.c code will be moving into kinit in patch #2, only enough to prove the system is working. #3 - move initrd to userspace Unfortunately we don't start seeing tangible benefits to early userspace until this patch, but that's how evolution works :) Here, initrd unpacking code is moved to userspace, as much as possible. Some initrd code will inevitably stay in the kernel, because it is arch-specific how to grab the initrd image from bootmem [or whereever], but the vast majority of initrd code goes poof (yay!). No initrd behavior will change at all, from current kernels. It is simply getting moved to early userspace. Users will not need to do anything on their end to make sure their existing setups continue to work -- any such actions are a bug on my part. This patch will also turn "kinit" into a shared binary, and introduce the gzip binary into early userspace. [see "Items For Discussion" below, too, WRT this.] #4 - move mounting root to userspace People probably breathed a sigh of relief at patch #3, they will heave a bigger sigh for this patch :) This moves mounting of the root filesystem to early userspace, including getting rid of NFSroot/bootp/dhcp code in the kernel. #N - to infinity... and beyond! I, and hopefully others, will continue in the series of evolutionary patches, moving more and more stuff to early userspace. There are a lot of possibilities, and I will be looking for input from others on useful things to move, as well as continuing my own work of finding items that can be moved. Items For Discussion #1 - shared kinit "kinit" is _the_ early userspace binary -- but not necessarily the only one. Peter Anvin and Russell King have several binaries in the klibc tarball, gzip, ash, and several smaller utilities. Peter also put work into making klibc a shared object -- that doesn't need an shlib loader. It's pretty nifty how he does it, IMO: klibc.so becomes an ELF interpreter for any klibc-linked binaries. klibc-linked binaries are, to the ELF system, static binaries, but they wind up sharing klibc.so anyway due to this trick. Anyway, there is a certain elegance in adding coding to kinit instead of an explosion of binaries and shell scripts. The other side of that coin is that with elegance you sacrifice some ease of making changes. I am 60% certain we want a shared klibc and multiple binaries, but am willing to be convinced in either direction. If you think about it, there _are_ several benefits to leaving kinit as the lone binary in the stock kernel early userspace build, so the decision is not as cut-n-dry as it may immediately seem. #2 - klibc in the kernel tarball It's going in, for now. That's not open to discussion. However, the future is... I know the old maxim of "once's it in, it never goes away." Maybe that's the case, and if so, no big deal. I know at least a couple people who would like to see it leave the kernel tarball before 2.6.0 is released. I solicit comments on this item, though I think we will won't be in a position to answer this question until 2.6.0 release is near. That's it for now. Questions, comments, and flames welcome. If I missed some early userspace benefits, let me know. If you know of good things to move to early userspace, let me know. If there are upcoming bumps in the road I did not mention, let me know. Credits: Al Viro for the initramfs work. hpa, rmk, Greg KH, Alan, and innumerable others have contributed ideas if not actual code towards this effort. And thanks to our Emporer Penguin for giving me a break, when I blew the Halloween deadline spending 24 hours debugging an _incredibly_ stupid bug on my part. I deserve not one but two brown paper bags for that one.