ramfs, rootfs and initramfs October 17, 2005 2005年10月17日 Rob Landley ============================= 日本語訳:吉山あきら ※訳注:原文で舌足らずな部分は訳文中の {} 中で補足するか、※で注釈を入 れました。 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 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 #include 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 で展開されます。これら3つを合わせても、全部で 可読のテキストフォーマット 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 に移植されるでしょ う。