エルドラド カジノ

JF Linux Kernel 3.x/2.6 Documentation: /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt


ramfs, rootfs, initramfs の説明 [プレインテキスト版]

ramfs, rootfs and initramfs
October 17, 2005
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

通常、全てのファイルは 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 のパッケージはあなたの為にこれら全
    (busybox のような)他のほとんどのパッケージはこのコマンドを 

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 メッセージを得るために、

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

したりデバイスノードを生成する際に 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 アーカイブを生成するスクリプトにし


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

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

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

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

initramfs アーカイブは完全な自己完結型の Linux 用ルートファイルシステ

The "klibc" package () 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 パッケージ()は、起動初
小さな C ライブラリと関連ユーティリティです。これは BSD ライセンスでライセンスされています。

I use uClibc () and busybox ()
myself.  These are LGPL and GPL, respectively.  (A self-contained initramfs
package is planned for the busybox 1.3 release.)

私自身は uClibc () と busybox
() を使用しています。これらはそれぞれ 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 します※)

        システムコール。ここでは静的リンクしたはずのバイナリが 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 () or
User Mode Linux, like so:

良い最初の一歩は、静的リンクされた「hello world」プログラムを init と
して実行する initramfs を作って、qemu () かUser Mode Linux 

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

  int main(int argc, char *argv[])
    printf("Hello world!\n");
  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.

できる事は良いことです。initramfs で相当するパラメータは

※訳注:「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月に遡ります。議論はここから始まりました。


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

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


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 記事があります。


   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 程人気がありません。しかし、このことはアーカイブの


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 は死ぬ程醜くてカーネル側で


   explained his reasoning:



   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 実装によって

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 カーネル 3.x/2.6 付属文書一覧へ戻る