ramfs，tmpfs, rootfs and initramfs

原文

ramfs, rootfs and initramfs
October 17, 2005
Rob Landley <rob@landley.net>
=============================

What is ramfs?
--------------

Ramfs is a very simple filesystem that exports Linux's disk caching
mechanisms (the page cache and dentry cache) as a dynamically resizable
RAM-based filesystem.

Normally all files are cached in memory by Linux.  Pages of data read from
backing store (usually the block device the filesystem is mounted on) are kept
around in case it's needed again, but marked as clean (freeable) in case the
Virtual Memory system needs the memory for something else.  Similarly, data
written to files is marked clean as soon as it has been written to backing
store, but kept around for caching purposes until the VM reallocates the
memory.  A similar mechanism (the dentry cache) greatly speeds up access to
directories.

With ramfs, there is no backing store.  Files written into ramfs allocate
dentries and page cache as usual, but there's nowhere to write them to.
This means the pages are never marked clean, so they can't be freed by the
VM when it's looking to recycle memory.

The amount of code required to implement ramfs is tiny, because all the
work is done by the existing Linux caching infrastructure.  Basically,
you're mounting the disk cache as a filesystem.  Because of this, ramfs is not
an optional component removable via menuconfig, since there would be negligible
space savings.

ramfs and ramdisk:
------------------

The older "ram disk" mechanism created a synthetic block device out of
an area of RAM and used it as backing store for a filesystem.  This block
device was of fixed size, so the filesystem mounted on it was of fixed
size.  Using a ram disk also required unnecessarily copying memory from the
fake block device into the page cache (and copying changes back out), as well
as creating and destroying dentries.  Plus it needed a filesystem driver
(such as ext2) to format and interpret this data.

Compared to ramfs, this wastes memory (and memory bus bandwidth), creates
unnecessary work for the CPU, and pollutes the CPU caches.  (There are tricks
to avoid this copying by playing with the page tables, but they're unpleasantly
complicated and turn out to be about as expensive as the copying anyway.)
More to the point, all the work ramfs is doing has to happen _anyway_,
since all file access goes through the page and dentry caches.  The RAM
disk is simply unnecessary; ramfs is internally much simpler.

Another reason ramdisks are semi-obsolete is that the introduction of
loopback devices offered a more flexible and convenient way to create
synthetic block devices, now from files instead of from chunks of memory.
See losetup (8) for details.

ramfs and tmpfs:
----------------

One downside of ramfs is you can keep writing data into it until you fill
up all memory, and the VM can't free it because the VM thinks that files
should get written to backing store (rather than swap space), but ramfs hasn't
got any backing store.  Because of this, only root (or a trusted user) should
be allowed write access to a ramfs mount.

A ramfs derivative called tmpfs was created to add size limits, and the ability
to write the data to swap space.  Normal users can be allowed write access to
tmpfs mounts.  See Documentation/filesystems/tmpfs.txt for more information.

What is rootfs?
---------------

Rootfs is a special instance of ramfs (or tmpfs, if that's enabled), which is
always present in 2.6 systems.  You can't unmount rootfs for approximately the
same reason you can't kill the init process; rather than having special code
to check for and handle an empty list, it's smaller and simpler for the kernel
to just make sure certain lists can't become empty.

Most systems just mount another filesystem over rootfs and ignore it.  The
amount of space an empty instance of ramfs takes up is tiny.

What is initramfs?
------------------

All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
extracted into rootfs when the kernel boots up.  After extracting, the kernel
checks to see if rootfs contains a file "init", and if so it executes it as PID
1.  If found, this init process is responsible for bringing the system the
rest of the way up, including locating and mounting the real root device (if
any).  If rootfs does not contain an init program after the embedded cpio
archive is extracted into it, the kernel will fall through to the older code
to locate and mount a root partition, then exec some variant of /sbin/init
out of that.

All this differs from the old initrd in several ways:

  - The old initrd was always a separate file, while the initramfs archive is
    linked into the linux kernel image.  (The directory linux-*/usr is devoted
    to generating this archive during the build.)

  - The old initrd file was a gzipped filesystem image (in some file format,
    such as ext2, that needed a driver built into the kernel), while the new
    initramfs archive is a gzipped cpio archive (like tar only simpler,
    see cpio(1) and Documentation/early-userspace/buffer-format.txt).  The
    kernel's cpio extraction code is not only extremely small, it's also
    __init text and data that can be discarded during the boot process.

  - The program run by the old initrd (which was called /initrd, not /init) did
    some setup and then returned to the kernel, while the init program from
    initramfs is not expected to return to the kernel.  (If /init needs to hand
    off control it can overmount / with a new root device and exec another init
    program.  See the switch_root utility, below.)

  - When switching another root device, initrd would pivot_root and then
    umount the ramdisk.  But initramfs is rootfs: you can neither pivot_root
    rootfs, nor unmount it.  Instead delete everything out of rootfs to
    free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
    with the new root (cd /newmount; mount --move . /; chroot .), attach
    stdin/stdout/stderr to the new /dev/console, and exec the new init.

    Since this is a remarkably persnickety process (and involves deleting
    commands before you can run them), the klibc package introduced a helper
    program (utils/run_init.c) to do all this for you.  Most other packages
    (such as busybox) have named this command "switch_root".

Populating initramfs:
---------------------

The 2.6 kernel build process always creates a gzipped cpio format initramfs
archive and links it into the resulting kernel binary.  By default, this
archive is empty (consuming 134 bytes on x86).

The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig,
and living in usr/Kconfig) can be used to specify a source for the
initramfs archive, which will automatically be incorporated into the
resulting binary.  This option can point to an existing gzipped cpio
archive, a directory containing files to be archived, or a text file
specification such as the following example:

  dir /dev 755 0 0
  nod /dev/console 644 0 0 c 5 1
  nod /dev/loop0 644 0 0 b 7 0
  dir /bin 755 1000 1000
  slink /bin/sh busybox 777 0 0
  file /bin/busybox initramfs/busybox 755 0 0
  dir /proc 755 0 0
  dir /sys 755 0 0
  dir /mnt 755 0 0
  file /init initramfs/init.sh 755 0 0

Run "usr/gen_init_cpio" (after the kernel build) to get a usage message
documenting the above file format.

One advantage of the configuration file is that root access is not required to
set permissions or create device nodes in the new archive.  (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.  See
Documentation/early-userspace/README for more details.)

The kernel does not depend on external cpio tools.  If you specify a
directory instead of a configuration file, the kernel's build infrastructure
creates a configuration file from that directory (usr/Makefile calls
scripts/gen_initramfs_list.sh), and proceeds to package up that directory
using the config file (by feeding it to usr/gen_init_cpio, which is created
from usr/gen_init_cpio.c).  The kernel's build-time cpio creation code is
entirely self-contained, and the kernel's boot-time extractor is also
(obviously) self-contained.

The one thing you might need external cpio utilities installed for is creating
or extracting your own preprepared cpio files to feed to the kernel build
(instead of a config file or directory).

The following command line can extract a cpio image (either by the above script
or by the kernel build) back into its component files:

  cpio -i -d -H newc -F initramfs_data.cpio --no-absolute-filenames

The following shell script can create a prebuilt cpio archive you can
use in place of the above config file:

  #!/bin/sh

  # Copyright 2006 Rob Landley <rob@landley.net> and TimeSys Corporation.
  # Licensed under GPL version 2

  if [ $# -ne 2 ]
  then
    echo "usage: mkinitramfs directory imagename.cpio.gz"
    exit 1
  fi

  if [ -d "$1" ]
  then
    echo "creating $2 from $1"
    (cd "$1"; find . | cpio -o -H newc | gzip) > "$2"
  else
    echo "First argument must be a directory"
    exit 1
  fi

Note: The cpio man page contains some bad advice that will break your initramfs
archive if you follow it.  It says "A typical way to generate the list
of filenames is with the find command; you should give find the -depth option
to minimize problems with permissions on directories that are unwritable or not
searchable."  Don't do this when creating initramfs.cpio.gz images, it won't
work.  The Linux kernel cpio extractor won't create files in a directory that
doesn't exist, so the directory entries must go before the files that go in
those directories.  The above script gets them in the right order.

External initramfs images:
--------------------------

If the kernel has initrd support enabled, an external cpio.gz archive can also
be passed into a 2.6 kernel in place of an initrd.  In this case, the kernel
will autodetect the type (initramfs, not initrd) and extract the external cpio
archive into rootfs before trying to run /init.

This has the memory efficiency advantages of initramfs (no ramdisk block
device) but the separate packaging of initrd (which is nice if you have
non-GPL code you'd like to run from initramfs, without conflating it with
the GPL licensed Linux kernel binary).

It can also be used to supplement the kernel's built-in initramfs image.  The
files in the external archive will overwrite any conflicting files in
the built-in initramfs archive.  Some distributors also prefer to customize
a single kernel image with task-specific initramfs images, without recompiling.

Contents of initramfs:
----------------------

An initramfs archive is a complete self-contained root filesystem for Linux.
If you don't already understand what shared libraries, devices, and paths
you need to get a minimal root filesystem up and running, here are some
references:
http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
http://www.linuxfromscratch.org/lfs/view/stable/

The "klibc" package (http://www.kernel.org/pub/linux/libs/klibc) is
designed to be a tiny C library to statically link early userspace
code against, along with some related utilities.  It is BSD licensed.

I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net)
myself.  These are LGPL and GPL, respectively.  (A self-contained initramfs
package is planned for the busybox 1.3 release.)

In theory you could use glibc, but that's not well suited for small embedded
uses like this.  (A "hello world" program statically linked against glibc is
over 400k.  With uClibc it's 7k.  Also note that glibc dlopens libnss to do
name lookups, even when otherwise statically linked.)

A good first step is to get initramfs to run a statically linked "hello world"
program as init, and test it under an emulator like qemu (www.qemu.org) or
User Mode Linux, like so:

  cat > hello.c << EOF
  #include <stdio.h>
  #include <unistd.h>

  int main(int argc, char *argv[])
  {
    printf("Hello world!\n");
    sleep(999999999);
  }
  EOF
  gcc -static hello.c -o init
  echo init | cpio -o -H newc | gzip > test.cpio.gz
  # Testing external initramfs using the initrd loading mechanism.
  qemu -kernel /boot/vmlinuz -initrd test.cpio.gz /dev/zero

When debugging a normal root filesystem, it's nice to be able to boot with
"init=/bin/sh".  The initramfs equivalent is "rdinit=/bin/sh", and it's
just as useful.

Why cpio rather than tar?
-------------------------

This decision was made back in December, 2001.  The discussion started here:

  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html

And spawned a second thread (specifically on tar vs cpio), starting here:

  http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html

The quick and dirty summary version (which is no substitute for reading
the above threads) is:

1) cpio is a standard.  It's decades old (from the AT&T days), and already
   widely used on Linux (inside RPM, Red Hat's device driver disks).  Here's
   a Linux Journal article about it from 1996:

      http://www.linuxjournal.com/article/1213

   It's not as popular as tar because the traditional cpio command line tools
   require _truly_hideous_ command line arguments.  But that says nothing
   either way about the archive format, and there are alternative tools,
   such as:

     http://freshmeat.net/projects/afio/

2) The cpio archive format chosen by the kernel is simpler and cleaner (and
   thus easier to create and parse) than any of the (literally dozens of)
   various tar archive formats.  The complete initramfs archive format is
   explained in buffer-format.txt, created in usr/gen_init_cpio.c, and
   extracted in init/initramfs.c.  All three together come to less than 26k
   total of human-readable text.

3) The GNU project standardizing on tar is approximately as relevant as
   Windows standardizing on zip.  Linux is not part of either, and is free
   to make its own technical decisions.

4) Since this is a kernel internal format, it could easily have been
   something brand new.  The kernel provides its own tools to create and
   extract this format anyway.  Using an existing standard was preferable,
   but not essential.

5) Al Viro made the decision (quote: "tar is ugly as hell and not going to be
   supported on the kernel side"):

      http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html

   explained his reasoning:

      http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
      http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html

   and, most importantly, designed and implemented the initramfs code.

Future directions:
------------------

Today (2.6.16), initramfs is always compiled in, but not always used.  The
kernel falls back to legacy boot code that is reached only if initramfs does
not contain an /init program.  The fallback is legacy code, there to ensure a
smooth transition and allowing early boot functionality to gradually move to
"early userspace" (I.E. initramfs).

The move to early userspace is necessary because finding and mounting the real
root device is complex.  Root partitions can span multiple devices (raid or
separate journal).  They can be out on the network (requiring dhcp, setting a
specific MAC address, logging into a server, etc).  They can live on removable
media, with dynamically allocated major/minor numbers and persistent naming
issues requiring a full udev implementation to sort out.  They can be
compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,
and so on.

This kind of complexity (which inevitably includes policy) is rightly handled
in userspace.  Both klibc and busybox/uClibc are working on simple initramfs
packages to drop into a kernel build.

The klibc package has now been accepted into Andrew Morton's 2.6.17-mm tree.
The kernel's current early boot code (partition detection, etc) will probably
be migrated into a default initramfs, automatically created and used by the
kernel build.

译文

ps:本文是Linux源码文档中ramfs-rootfs-initramfs.txt的一个翻译，由于水平有限译文中有许多不足之处。

ramfs, rootfs and initramfs
October 17, 2005
Rob Landley <rob@landley.net>
译者：wstone_h <wstoneh at 126.com>
初次发布：2009-3-8
版权申明：本译文以 知识共享“署名-非商业性使用-相同方式共享 2.5 中国大陆”许可协议进行共享

ramfs是什么

ramfs是一个非常简单的文件系统，它输出Linux的磁盘缓存机制(页缓存和目录缓存)作为一个大小动态的基于内存的文件系统。

通常，所有的文件由Linux被缓存在内存中。页的数据从后备存储(一般被挂载的是块设备文件系统)中读取，这些数据保持在周围以防再次需要。但是这些数据被标记为可用(空闲)以防虚拟内存系统(Virtual MemorySystem)需要这些内存作为别用。类似的，在数据写回后备存储时，数据一写回文件就立即被标记为可用，但周围的缓存被保留着直至VM(虚拟内存系统)重新分配内存。一个类似的机制(目录缓存)极大的加快了对目录的访问。

ramfs并没有后备存储。文件写入ramfs象往常一样，来分配目录和页的缓存，但这里并没有地方可写回它们。这意味着 页的数据不再标记为可用，因此当 希望回收内存时，内存不能通过VM来释放。

实现ramfs所需的代码总量是极少的，因为所有的工作由现有的Linux缓存结构来完成。实际上，你现正在挂载磁盘缓存作为一个文件系统。据此，ramfs并不是一个可通过菜单配置项来卸载的可选组件，它可节省的空间是微不足道的。

ramfs和ramdisk

旧的"ram disk"机制在一个内存空间中创建一个合成块设备，并使用它作为一个文件系统的后备存储。这个块设备是 固定大小的以至于挂载在它上面的文件系统也是固定大小的。除创建和销毁目录外，使用一个内存磁盘并需要额外的内存拷贝——从假的块设备到页缓存拷贝内存数据(和拷贝更改回退)。另外，它需要一个文件系统驱动(如，ext2)来格式和解释这些数据。

与ramfs相比较，这些废弃的内存(和内存总线带宽)为CPU造成了不必要的工作，并污染了CPU缓存。(这里有个技巧通过使用页表单来避免这个拷贝，但是这些技巧很复杂并且代价反而变的与拷贝一样昂贵。)更为重要的是，由于所有的文件都通过页和目录缓存进行访问，全部的工作ramfs（ ram disk？）都要执行。内存磁盘是完全没必要的( simply unnecessary)，ramfs在内部更为简单。

另一个ramdisks是半过时的理由是：它引进的回环设备提供一个更灵活和方便的方式从文件来创建一个合成块设备，而不是从大块的内存中来创建。
参见losetup (8) 来获得有关细节。

ramfs和tmpfs

ramfs的一个不利之处是你将保留写回到ramfs的数据直至你填补所有的内存，并且VM不能释放它，因为VM考虑到文件将写回后备存储(而不是交换空间)，但是ramfs并不能获得任何的后备存储。据此，只有 root(或者一个受信任的用户)可允许回写到一个ramfs挂载中。

一个ramfs派生出tmpfs来添加大小的限制以及回写数据到交换空间的能力。普通用户可以允许回写到tmpfs挂载中。

参见Documentation/filesystems/tmpfs.txt来获得更多信息。

rootfs是什么

rootfs是一个特定的ramfs(或tmpfs，如果那被启用)的实例，它始终存在于2.6的系统。你不能卸载rootfs，这个理由近似于你不能杀死init进程。它小巧且简单的为内核确保某些列表不能为空，而不是拥有特定的代码来检查和处理一个空列表。

大多数的系统挂载另一个文件系统到rootfs并忽略它。一个空白ramfs实例的空间总量占用是极小的。

rootfs是一种特定的ramfs的实例，它一直存在于系统中，不能卸载。大部分其他的文件系统安装于rootfs之上。

initramfs是什么

所有的2.6Linux内核包含了一个gzip压缩过的"cpio"格式存档，当内核启动时它将被提取到rootfs。在提取之后，内核检测rootfs是否包含了一个"init"文件，如果包含就来执行它并设置PID为1。如果找到，这个init进程将负责引导系统的其余内容，包含了要寻找和挂载的真正根设备(若有的话)。如果rootfs在提取cpio存档以后并不包含一个init程序，内核将失败并通过旧的代码来寻找和挂载一个根分区，接着执行一些/sbin/init的变种。

当linux内核启动后，会找到并执行第一个用户程序，一般是init。这个程序存在于文件系统当中，文件系统存在于设备上，但不知道init存在哪个设备上，于是有了内核命令列选项root=，用来指定root文件系统存在于哪个设备上。

然后由于后来的设备类型越来越来多，比如可能在scsi,sata,flash这些设备，还有的存在于网络设备上，不可能把这些设备的驱动编译进内核，这样内核就会越来越来大。为了解决这些问题，出现了基于ram的文件系统，initramfs,这个文件系统可以包含多个目录和程序init,然后通过这个程序，内核再用这个程序去挂载真正的要文件系统。如果没有这个程序，内核可以来寻找和挂载一个根分区，接着执行一些/sbin/init的变种。

与旧的initrd有以下几点不同:
- 旧的initrd通常是一个独立的文件，而initramfs存档是连接到linux内核映像的。(Linux系统目录-*/usr 在构建时就是为了生成这个存档)

-旧的initrd文件是一个gzip压缩过的文件系统映像(在一些文件格式，如ext2,需要构建一个驱动到内核)，而这个新的initramfs存档是一个gzip压缩过的cpio存档(象tar一样简单，参见cpio(1) andDocumentation/early-userspace/buffer-format.txt)。内核的cpio提取代码不仅极少，而且init文本和数据可以在启动过程中被丢弃。

-程序通过旧的initrd(叫做/initrd，而不是/init)运行一些设定并接着返回内核，而init程序从initramfs并不预计返回内核。(如果/init需要手工关闭并控制它，可以与一个新的根设备一起覆盖挂载 / 并执行另一个init程序。参见switch_rootutility的后部分)

-当切换到另一个根设备，initrd会pivot_root并且接着卸载内存磁盘。但是initramfs是rootfs：你可以不用pivot_root rootfs和卸载它。而是删除除rootfs之外的所有东西来释放空间(find -xdev / -exec rm'{}' ';'),与新的根(cd /newmount; mount --move . /; chroot.)一起覆盖挂载rootfs,附加stdin/stdout/stderr到新的/dev/console并执行新的init。

由于这是一个非常谨慎的进程(以及在你运行它们之前涉及到删除命令)，klibc包为你引进了一个帮助程序(utils/run_init.c)来做这些。大部分其他软件包(如，busybox)已命名在此命令"switch_root"中。

提供 initramfs

v2.6 内核构建进程总是创建一个gzip压缩过的cpio格式的initramfs存档并连接它到生成的内核二进制文件。默认的，这些存储是空的(在x86上占用134 bytes)

配置选项CONFIG_INITRAMFS_SOURCE(存在于menuconfig的GeneralSetup选项和usr/Kconfig中)可为initramfs存档使用特定的一个源文件，它自动合并到生成的二进制文件中。这个选项可以指定一个现有的gzip压缩的cpio存档，这个存档可以包含一个目录文件到或者是一个文本文件详述，如下面的示例:

dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
nod /dev/loop0 644 0 0 b 7 0
dir /bin 755 1000 1000
slink /bin/sh busybox 777 0 0
file /bin/busybox initramfs/busybox 755 0 0
dir /proc 755 0 0
dir /sys 755 0 0
dir /mnt 755 0 0
file /init initramfs/init.sh 755 0 0

在文件格式之上运行"usr/gen_init_cpio"(在构建内核之后)来获得一个用法文档。

一个高级的配置文件是root访问不需要在新的存档上设置权限或者创建设备节点。(注意示例的那两个"file"期望在linux-2.6.*目录下，在"initramfs"目录中找到名为"init.sh"和"busybox"的文件。参见Documentation/early-userspace/README 以获得更多细节。)

内核并不依赖外部的cpio工具。如果你指定一个目录而不是一个配置文件，内核的构建结构将从那个目录(usr/Makefile 调用
scripts/gen_initramfs_list.sh)创建一个配置文件，并封装该目录来使用配置文件(通过释放它到从usr/gen_init_cpio.c 创建的usr/gen_init_cpio)。在内核构建时cpio创建的代码是完全独立的，在内核开启时提取器也是(完全)独立的。

你唯一可能需要为创建或提取你自己的cpio文件以提供给内核构建(而不是一个配置文件或目录)而安装外部的cpio工具。

以下的命令行可提取一个cpio映像(不管是通过以上脚本或是通过内核构建成的)回退到它的组成文件：
cpio -i -d -H newc -F initramfs_data.cpio --no-absolute-filenames

以下的shell脚本可创建一个预制的cpio存档，你可以使用在上述的配置文件中：

#!/bin/sh

# Copyright 2006 Rob Landley <rob@landley.net> and TimeSys Corporation.
# Licensed under GPL version 2

if [ $# -ne 2 ]
then
    echo "usage: mkinitramfs directory imagename.cpio.gz"
    exit 1
fi

if [ -d "$1" ]
then
    echo "creating $2 from $1"
    (cd "$1"; find . | cpio -o -H newc | gzip) > "$2"
else
    echo "First argument must be a directory"
    exit 1
fi

注意：如果你是按照cpio的man页做的，那么它包含的一些不良建议将会破坏你的initramfs存档。它说"生成文件名列表的一个典型方式是使用find命令，你应该提供-depth选项来搜索"。而在创建initramfs.cpio.gz映像时不要这么做，因为它并不可行。Linux内核的cpio提取器不会在一个不存在的目录中创建文件，因此目录项必须在文件被提取到该目录之前被提取。以上脚本保证了它们的顺序正确性。

外部initramfs映像

如果内核有启用initrd支持，一个外部的cpio.gz存档也可替换一个2.6 内核的initrd。既然这样，内核将自动检测文件类型(initramfs, 而不是initrd)并在尝试运行/init前，提取外部的cpio存档到rootfs。

initramfs有内存效率的优势(没有内存磁盘块设备)，而initrd可单独封装(如果你有非GPL许可协议的代码，而你想从initramfs运行，这还是不错的。不要与GPL许可的二进制的Linux内核混为一谈)。

外部initramfs映像也可以用来补充内核内建的initramfs映像。外部存档文件将覆盖与内建initramfs存档中任意不一致的文件。一些发行商也偏爱定制一个单一内核映像和特定initramfs映像，而不用重编译。

initramfs的内容

一个initramfs存档是一个完整独立的Linux根文件系统。如果你还不能理解共享库、设备和路径，你需要获得一个小的根文件系统来启动和运行，这里有一些参考资料：
http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
http://www.linuxfromscratch.org/lfs/view/stable/

软件包"klibc"(http://www.kernel.org/pub/linux/libs/klibc)被设计为一个极小的C库来静态连接早期的用户空间代码，以及一些相关的工具。它是BSD授权。

我使用uClibc (http://www.uclibc.org)和busybox (http://www.busybox.net)。这些分别是LGPL和GPL授权。(一个独立的initramfs软件包被计划在busybox 1.3 release。)

从理论上说你可以使用glibc，但是对于小型嵌入式系统象这样使用并适合。(一个"hello world"程序静态连接glibc将近400k。用uClibc的话它是7k。还要注意，glibc dlopens libnss作为名称查找，即使是使用静态连接。)

一个好的开头是获得initramfs来运行一个静态连接的"hello world"程序作为init，并在一个类似qemu(www.qemu.org)的仿真器或用户模式的Linux中测试它，象这样：
cat > hello.c << EOF
#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    printf("Hello world!/n");
    sleep(999999999);
}
EOF
gcc -static hello.c -o init
echo init | cpio -o -H newc | gzip > test.cpio.gz
# Testing external initramfs using the initrd loading mechanism.
qemu -kernel /boot/vmlinuz -initrd test.cpio.gz /dev/zero

当调试一个普通根文件系统时，能够用"init=/bin/sh"来启动将是不错的。与initramfs等价的是"rdinit=/bin/sh"，而且它很有用。

为什么是cpio而不是tar?

这个决定的发布是在2001年12月。讨论浏览在这里:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1538.html

并且催生了第二件事情(tar与cpio的比较)，浏览这里
http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1587.html

快速且直接的总结版本(这些是无法替代上述内容的阅读的)：
1) cpio是一个标准。它十来岁了(从 AT&T起)，并已被广泛应用在Linux上(在RPM中，Red Hat的设备驱动磁盘上)。这里有从1996年起有关它的Linux日志：
http://www.linuxjournal.com/article/1213

它并没有象tar一样流行，因为传统的cpio命令行工具要求使用极可怕的命令行。同时没有其他有关存档格式的方式，并有可选的工具。如:
http://freshmeat.net/projects/afio/

2)cpio存档格式是由内核选择的，它比(许多国家的)任意的tar存档格式都简单且干净(并极容易来创建和解析)。完整的initramfs存档格式说明在buffer-format.txt，创建在usr/gen_init_cpio.c，并提取在init/initramfs.c。所有三个可阅读的文本一起不到26k。

3) GNU项目使用tar标准似乎是与Windows使用zip的标准相关。Linux并不是它们中任一一个，并自由的作出了自己的技术决策。

4) 由于这是一个内核的内部格式，它可以很容易做一些更新。内核提供它自己的工具来创建和提取这个格式。使用现有的标准是可取的，但不是必要的。

5) Al Viro 作出决定(引用: "tar is ugly as hell and not going to be supported on the kernel side"):
http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1540.html

解释它的理由：
http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1550.html
http://www.uwsg.iu.edu/hypermail/linux/kernel/0112.2/1638.html

最重要的是，设计和实现initramfs的代码。

发展的方向

当前(2.6.16), initramfs总被编译进，但并没总被使用。内核做到回退到原来的启动代码只需initramfs中不包含一个/init程序。回退
是原来的代码，以此确保一个平滑的过渡并允许尽早的开启功能逐步移动到"前期用户空间"(即initramfs)。

移动到前期用户空间是必要的，因为寻找和挂载真正的根设备是复杂的。根分区可以跨多个设备。它们可在网络上进行(要求dhcp，设定一个特定MAC地址，登录到一台服务器等)。它们可用在可移动媒体，动态分配主/次号以及要求udev执行清理的持续命名的问题。它们可被压缩、加密、写时拷贝，回环挂载、异常分区等。

这种复杂性(必将包含的策略)是在用户空间的处理的正确性。klibc和busybox/uClibc两者一起在简单的initramfs软件包中工作以组成一个内核构建。

软件包klibc现在已被Andrew Morton's 2.6.17-mm 接受到树中。内核当前的提前启动代码(分区检测等)可能会迁移到默认的initramfs中，由内核构建自动创建并使用。

initramfs和rootfs之间的关系

当内核启动的时候，会先注册和挂载一个虚拟的根文件系统，也就是rootfs，然后会把做好的initramfs(这个可以自己制作)中的文件解压到rootfs中。然后系统会挂载真的根文件系统，rootfs隐藏之后。

我的开发板上的u-boot传送的参数为noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0,115200 mem=64M。

noinitrd的含义

(仅当内核配置了选项 CONFIG_BLK_DEV_RAM和CONFIG_BLK_DEV_INITRD)现在的内核都可以支持initrd了，引导进程首先装载内核和一个初始化的ramdisk，然后内核将initrd转换成普通的ramdisk，也就是读写模式的根文件系统设备。然后linuxrc执行，然后装载真正的根文件系统，之后ramdisk被卸载，最后执行启动序列，比如/sbin/init。

选项noinitrd告诉内核不执行上面的步骤，即使内核编译了initrd，而是把initrd的数据写到 /dev/initrd，只是这是一个一次性的设备。

http://blog.csdn.net/hongdatong/article/details/4019328

http://www.linuxidc.com/Linux/2011-10/45448.htm