Linux Kernel 2.6 Documentation:

filesystems/ramfs-rootfs-initramfs.txt

• 原著作者: Rob Landley <rob at landley dot net>
• 翻訳者: Akira YOSHIYAMA <yosshy at debian dot or dot jp>
• バージョン: 2.6.18
• 翻訳日時: 2007/01/28

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

日本語訳：吉山あきら <yosshy＠debian.or.jp>


※訳注：原文で舌足らずな部分は訳文中の {} 中で補足するか、※で注釈を入
        れました。


What is ramfs?
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.

ramfs は Linux のディスクキャッシュ機構(ページキャッシュと dentry の
キャッシュ）を動的にサイズが変化する RAM ベースのファイルシステムとし
て表に出した非常にシンプルなファイルシステムです。

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.

通常、全てのファイルは Linux によってメモリ上にキャッシュされます。二
次記憶装置(通常はそのファイルシステムがマウントされたブロックデバイス) 
から読み込まれたデータのページは、それが再度必要とされる場合に備えて
{ページキャッシュとして}保持されており、仮想メモリシステムが他でメモリ
が必要と判断した場合に{再利用できるように} clean (開放可能)とマークさ
れます。同様に、ファイルに書き込まれたデータは、二次記憶装置に書き込ま
れたらすぐに clean とマークされますが、仮想メモリ機構がメモリを再割り
当てしない限りキャッシュ目的で保持されます。同様の機構(dentry キャッシュ)
はディレクトリアクセスを劇的に高速化します。

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.

ramfs では、二次記憶装置がありません。ramfs に書き込まれたファイルは 
普通{のファイルシステム}と同じように dentry やページキャッシュを使用し
ますが、これらが書き込まれる先はどこにもありません。これは、これらのペー
ジは決して clean とマークされる事がなく、それゆえ仮想メモリ機構が{開放
可能な}メモリを再利用するために探す際にも、これらのページが開放できま
せん。

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 では}すべての作業が既存の Linux キャッシュ管理機構によって行わ
れるため、ramfs を実装する為に必要なコード量はわずかです。基本的に、
{ramfs は}ディスクキャッシュをファイルシステムとしてマウントします。こ
のため、ramfs は menuconfig {Linux カーネル構築時の設定}で削除可能なオ
プション要素ではありませんし、省いたとしても節約できるサイズはごくわず
かでしょう。

ramfs and ramdisk:
ramfs と RAM ディスク：
------------------

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.

より古い「RAM ディスク」機構は RAM 上の一角に疑似ブロックデバイスを作
り、これをファイルシステムの二次記憶装置として使用していました。このブ
ロックデバイスは固定サイズなので、この上にマウントされたファイルシステ
ムも固定サイズでした。RAM ディスクを使用する事はまた、疑似ブロックデバ
イスからページキャッシュへ(それとページの更新を疑似ブロックデバイスへ)
の不必要なメモリコピーが必要で、また dentry の生成・削除でも同様でした。
加えて、RAM ディスクはそのデータをフォーマットして解釈する為の(ext2 の
ような)ファイルシステムドライバが必要でした。

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.

ramfs と比較して、RAM ディスクはメモリ(とメモリのバスバンド幅)を無駄に
し、余計な CPU 負荷を生成し、CPU キャッシュを汚します(ページテーブルを
いじってこれらのコピーを回避するトリックがありますが、これらは嬉しくな
いことに複雑で、コピーするのと同様にコストがかかる事が分かっています)。
付け加えれば、全てのファイルはページと dentry キャッシュを通してアクセ
スされるので、ramfs の動作は「どんな場合でも」起こるものなのです。RAM 
ディスクは単に不要であり、ramfs は内部的にずっとシンプルです。

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.

RAM ディスクが過去の物となりつつある別の理由は、loopback デバイスの導
入が、メモリの塊 (chunks) からではなくファイルから疑似ブロックデバイス
を作成するためのより柔軟で快適な手段を提供している事です。詳細は 
losetup (8) を参照して下さい。

ramfs and tmpfs:
ramfs と 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.

ramfs のマイナス面は、ramfs に書き込んだデータで全てのメモリを埋める事
ができ、また VM がそのメモリを開放できない事です。なぜなら、VM は書き
込まれたファイルを(スワップスペースではなく)二次記憶装置に書き込もうと
しますが、ramfs には二次記憶装置がないからです。このため、root (または
信用できる1ユーザ) のみ ramfs マウントに対する書き込みアクセスを許可す
べきです。

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.

tmpfs と呼ばれる ramfs の派生物は、{ファイルシステムに}サイズ制限を加
える為とデータをスワップスペースに出力可能にする為に作られました。一般
ユーザに tmpfs マウントへの書き込みアクセスを許可できます。これ以上の
情報は Documentation/filesystems/tmpfs.txt を参照して下さい。

What is rootfs?
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.

rootfs は ramfs (または有効ならば tmpfs) の特別な存在であり、カーネル 
2.6 のシステムでは常に存在しています。init プロセスを kill できないの
とほぼ同様の理由で、rootfs はアンマウントできません。つまり空リストを
チェックして扱う為の特別なコードを持つより、単にある種のリストが空にな
らない事を保証した方がカーネルにとって小さくおさまりシンプルな為です。

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

ほとんどのシステムは rootfs の上に別のファイルシステムをマウントし、
rootfs を無視します。空の ramfs のメモリ使用量はごくわずかです。

What is initramfs?
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.

全ての 2.6 系 Linux カーネルは gzip 圧縮された「cpio」フォーマットのアー
カイブを含んでおり、これはカーネルが起動する際に rootfs に展開されます。
展開後、カーネルは rootfs が「init」ファイルを含んでいるかどうか確認し、
あれば PID 1 ※として実行されます。この場合、この init プロセスはシス
テム起動の残りの部分の責任を持ち、それには(もしあれば)本物のルートデバ
イスの特定とマウントが含まれます。埋め込まれた cpio アーカイブの展開後、
rootfs が init プログラムを含んでいなかった場合は、カーネルはルートパー
ティションを特定してマウントする古いコードに立ち戻り、rootfs の外の 
/sbin/init の類を実行します。

※訳注：カーネルが起動した唯一かつ最初のユーザプロセスの事。
        プロセス ID (PID) が 1 になります。

All this differs from the old initrd in several ways:

これは古い initrd とは幾つかの部分で異なります：

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

  - 古い initrd は常に単独のファイルでしたが、initramfs アーカイブは 
    Linux カーネルイメージにリンクされます。(linux-*/usr ディレクトリ
    はカーネル構築中にこのアーカイブを作成する為の物です)

  - 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 data that can be discarded during the boot process.

  - 古い initrd ファイルは gzip 圧縮されたファイルシステムイメージ
    (ext2 のようないくつかのファイルフォーマットで、カーネルにドライバ
    を組み込んでおく必要あり)でしたが、新しい initramfs アーカイブは 
    gzip 圧縮された cpio アーカイブ(tar のようなもので単によりシンプル、
    詳細は cpio(1) マニュアルと
    Documentation/early-userspace/buffer-format.txt 参照)です。カーネ
    ルの cpio 展開コードはただ非常に小さいだけではなく、起動プロセスの
    間に破棄可能な __init データでもあります。

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

  - 古い initrd によって実行されるプログラム(/init ではなく /initrd と
    呼ばれる)は幾つかのセットアップを行ってその後カーネルに戻りますが、
    initramfs の init プログラムはカーネルに戻ることを前提としていませ
    ん。(もし /init が制御を開放する必要があれば、/ を新しいルートデバ
    イスで上書きマウントし、別の init を起動する事ができます。後述の 
    switch_root ユーティリティを参照下さい)

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

  - 別の root デバイスに切替える際、initrd では pivot_root ※し、それ
    から RAM ディスクをアンマウントしていました。一方、initramfs は 
    rootfs です：rootfs は pivot_root できませんし、アンマウントする事
    もできません。代わりに、そのメモリ空間を開放するために rootfs の全
    てを消去し(find -xdev / -exec rm '{}' ';')、新しいルートデバイスで
    上からマウントします(cd /newmount; mount --move . /; chroot .)。標
    準入力/標準出力/標準エラー出力を新しい /dev/console にアタッチして、
    新しい init を実行します。

※訳注：ルートファイルシステムを入れ換えるシステムコール、またはそのコマンド

    Since this is a remarkably persnickity 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".

    これは非常に好嫌いの激しい手順(しかもそれらを実行する前にコマンド
    の消去を伴う)であるので、klibc のパッケージはあなたの為にこれら全
    てを行うヘルパープログラム(utils/run_init.c)を導入しました。
    (busybox のような)他のほとんどのパッケージはこのコマンドを 
    「switch_root」と名付けています。

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

2.6 カーネルの構築過程は常に gzip された cpio フォーマットの initramfs 
アーカイブを作成し、これを構築されたカーネルバイナリにリンクします。通
常、このアーカイブは空です(x86 上では 134 バイト消費します)。

The config option CONFIG_INITRAMFS_SOURCE (for some reason buried under
devices->block devices 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:

設定オプション CONFIG_INITRAMFS_SOURCE(いくつかの理由で、menuconfig で
は devices->block デバイスの欄に表示され、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

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

上記のファイルフォーマットが説明した usage メッセージを得るために、
(カーネル構築後)「usr/gen_init_cpio」を実行して下さい。

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

この設定ファイルの1つの利点は、新しいアーカイブにパーミッションを設定
したりデバイスノードを生成する際に root アクセスが必要ないという事です。
(この2つの file エントリの例では、linux-2.6.* ディレクトリ下の 
initramfs というディレクトリ中に init.sh と busybox というファイルがあ
る事を仮定しています。詳細は Documentation/early-userspace/README を参
照して下さい)

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.

カーネルは外部の cpio ツールに依存していません。もし設定ファイルではな
くディレクトリを指定した場合は、カーネルの構築基盤はこのディレクトリか
ら設定ファイルを生成し(usr/Makefile は scripts/gen_initramfs_list.sh 
を実行します)、この設定ファイルを使用してディレクトリのパッケージ化を
処理します(この設定ファイルを、usr/gen_init_cpio.c から生成された 
usr/gen_init_cpio に食わせます)。カーネルの構築時の cpio 生成コードは
完全にカーネルソースに含まれており、カーネルの起動時の cpio 展開コード
もまた(当り前ですが)カーネルに含まれています。

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

外部のインストール済の cpio ユーティリティが必要になる1つのケースは、
カーネル構築に食わせる為に(設定ファイルやディレクトリではなく)あなた自
身が準備した cpio ファイルを生成または展開する事です。

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 イメージをその構成ファイル群に展開します：

  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:

以下のシェルスクリプトで、構築済みの cpio アーカイブが生成できます。
このスクリプトは、上記の設定ファイルの代わりに使えます：

訳注：説明では「設定ファイル」を用いるとありますが、下記は指定されたディ
        レクトリ下から cpio + gzip アーカイブを生成するスクリプトにし
        か見えません。

  #!/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.

注：cpio マニュアルページは、その通りに行うとあなたの initramfs アーカ
イブを壊してしまう幾つかの悪いアドバイスを含んでいます。曰く、「ファイ
ル名の一覧を作る典型的な方法は find コマンドを用いる事で、書き込み不可
またはサーチ不可なディレクトリ上のパーミッションによる問題を最小化する
為に find コマンドに -depth オプションを与えるべきです。」
initramfs.cpio.gz イメージを作成する際はこの通りにしないで下さい。やっ
た場合は動きません。Linux カーネルの cpio 展開ルーチンは、ディレクトリ
が存在しない場合にはその中のファイルを生成しませんので、ディレクトリ中
のファイル群のエントリの前にそのディレクトリのエントリが来ないといけま
せん。上記のスクリプトは一覧を正しい順序で得ます。


External initramfs images:
外部の initramfs イメージ：
--------------------------

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.

カーネルの initrd サポートを有効にした場合、initrd の代わりに外部の 
cpio.gz アーカイブを 2.6 カーネルに渡す事もできます。この場合、カーネ
ルは自動的にそのタイプ(initd ではなく initramfs)を検知し、/init の実行
を試す前に外部の cpio アーカイブを rootfs に展開します。

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

これは、(RAM ディスクのブロックデバイスのない)initramfs のメモリ効率上
のメリットの他に、initrd の分離したパッケージングというメリットがあり
ます。(非 GPL のコードを initramfs から実行したい場合に、Linux カーネ
ルバイナリの GPL ライセンスと衝突しないので良い)

It can also be used to supplement the kernel's built-in initamfs 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.

これはカーネルに組み込まれた initramfs イメージを補足する為にも使用さ
れます。外部アーカイブ中のファイル群は、カーネルに組み込まれた 
initramfs アーカイブ内の競合するファイル群を上書きします。幾つかのディ
ストリビューターも、リコンパイルせずに単一のカーネルイメージを用途別の 
initramfs イメージでカスタマイズする方法を好みます。

Contents of initramfs:
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:

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/

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.

klibc パッケージ(http://www.kernel.org/pub/linux/libs/klibc)は、起動初
期段階のユーザ空間のコードに対して静的リンクするようにデザインされた
小さな C ライブラリと関連ユーティリティです。これは BSD ライセンスでライセンスされています。

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

私自身は uClibc (http://www.uclibc.org) と busybox
(http://www.busybox.net) を使用しています。これらはそれぞれ LPGL と 
GPL でライセンスされています。(自己完結型の initramfs パッケージは 
busybox 1.3 リリースで計画されています)

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

理論的には glibc を使用しても良いのですが、glibc はこのような小規模な
組み込み利用にはあまり向いていません。(glibc に静的リンクされた「Hello
world」プログラム{のサイズ}は 400kB を超えています。uClibc だと 7kB で
す。また、glibc はスタティックリンクしたとしても、ネットワーク名の解決
をする為に libnss を dlopen します※)

※訳注：dlopen…プログラム起動後に共有ライブラリを追加で動的リンクする
        システムコール。ここでは静的リンクしたはずのバイナリが libnss 
        を動的リンクする事を問題視しています。

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:

良い最初の一歩は、静的リンクされた「hello world」プログラムを init と
して実行する initramfs を作って、qemu (www.qemu.org) かUser Mode 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 hello2.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.

通常のルートファイルシステムをデバッグする際、「init=/bin/sh」※で起動
できる事は良いことです。initramfs で相当するパラメータは
「rdinit=/bin/sh」※で、これは本当に便利です。

※訳注：「init=」「rdinit=」共に Linux のカーネルコマンドラインオプショ
        ンで、ブートローダや qemu/UML 等の実行時に指定します。

Why cpio rather than tar?
何故 tar でなく cpio なのか？
-------------------------

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

この決断は 2001年12月に遡ります。議論はここから始まりました。

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

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

(tar 対 cpio に特化して) 2つ目の議論がここから再燃しました：

  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:

簡易で荒い概要版 (2つの議論全体を読む代わりにはなりません) は：

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:

1) cpio は1つの標準です。これは年代物(AT&T 時代から)であり、既に Linux 
   で広く使用されています (RPM や Red Hat のデバイスドライバディスク内
   で)。ここに 1996 年の cpio に関する Linux Journal 記事があります。

      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:

   伝統的な cpio コマンドラインツールが「実に酷い」引数群を必要とする
   為、cpio は tar 程人気がありません。しかし、このことはアーカイブの
   フォーマットの優劣とは関係ありません。下記のような代替ツールがあり
   ます：

     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.

2) カーネルが選択した cpio アーカイブフォーマットは、(文字どおり何ダー
   スもある)数々の tar のアーカイブフォーマットのどれよりも単純かつき
   れい(従って生成や解読が簡単)です。完全な initramfs アーカイブフォー
   マットは buffer-format.txt に記述され、usr/gen_init_cpio.c で生成さ
   れ、init/initramfs.c で展開されます。これら３つを合わせても、全部で
   可読のテキストフォーマット 26kB 未満になります。

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.

3) tar の GNU プロジェクト標準化は、おおむね zip の Windows 標準化に類
   似しています。Linux はそのどちらでもありませんし、独自の技術的決定
   をする事は自由です。

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.

4) これはカーネルの内部フォーマットであるため、簡単に何か新しい物に変
   える事ができます。少なくともカーネルはこのフォーマットを生成・展開
   する独自のツールを提供しています。既存の標準の使用は望ましくはあり
   ますが、不可欠ではありません。

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

5) Al Viro が決定を下しました (引用：「tar は死ぬ程醜くてカーネル側で
   サポートしたくない」)

      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.

   また、一番大事な事は、initramfs コードが設計・実装された事です。

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

現在(2.6.16)、initramfs は常に組み込まれていますが、常に使われているわ
けではありません。initramfs が /init プログラムを含んでいなかった場合
のみ、カーネルは古い起動コードを代わりに実行します。この代替策は古いコー
ドの円滑な移行を保証するため、つまり起動初期機能(early boot
functionality) を「起動初期ユーザスペース」(即ち 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.


起動初期ユーザスペースへの移行が必要なのは、実ルートデバイスの検出とマ
ウントが複雑なためです。ルートパーティションは複数のデバイスに分散する
事があります(RAID または分離ジャーナル)。ルートパーティションはネット
ワーク越しになる事があります(DHCP、特定の MAC アドレスの設定、サーバへ
のログイン、等)。ン、等が必要な場合があります)。ルートパーティションが
リムーバブルメディア上にある場合は、動的にデバイスのメジャー／マイナー
番号が付けられており、固定名称とするためには、完全な udev 実装によって
解決しなければなりません。ルートパーティションは圧縮、暗号化、
copy-on-write、ループバックマウント、特殊な分割、その他あれこれされる
事があります。

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.

この種の複雑さ(必然的にポリシーを含む)はユーザスペースで扱うのが適切で
す。klibc と busybox/uClibc はどちらも、単純な initramfs パッケージを
カーネルビルドに含める場合に利用できます。

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.

klibc パッケージは現在、Andrew Morton の 2.6.17-mm ツリーに含まれてい
ます。カーネルの現在の早期起動コード(パーティション検出等)は多分、カー
ネル構築時に自動的に作成されるデフォルトの initramfs に移植されるでしょ
う。

Linux カーネル 2.6 付属文書一覧へ戻る