ここまでの調査のまとめ

勘違いもあるかもしれんが、とりあえず書き出して頭をすっきりさせたい。

実装としてのfsとサービスとしてのfs（ボリューム？）がある。
-サービスとしてのfsは、実装としてのfsとデータと名前を持つ。
- ramfsは実装(VFSのcache機構を利用している。dirtyなままなcache)
- rdは実装(block deviceなram disk, １ファイル・・・。）のためのdiskで中身はext3とか？
- initrdはfsじゃないサービスで、rdをrootとしてmountする。これができた当時はrootfsがなかった。
- initramfsはサービスとしてのfs。
実装はramfsで、format はcpio
- rootfsはサービスとしてのfs。
　実装はramfs？
ほかのfs(サービスとしてのfs)をマウントするためのfs、すべてをぶら下げるための「出っ張り」

initramfsは、/initのための情報・コードが入っている。ので、initramfs内での位置をカーネルが知っていないとシステムが立ち上がらない(カーネルイメージにリンクされる）。立ち上がったあと、switch_rootで本来のHDDやらなにやらからなるfsをrootfsにmountする。

んで～～～なんでkernel以外にfile systemにおいておきたいモノがあるのか？
それらは何かという問いに答えると多分すっきりする。

early-userspace
より抜粋
Linux カーネルのブート中に利用可能である必要はあるのだけれども
カーネル自身の内部で実行する必要はない
ものが詰まっている。

ではそれらは具体的になんであってどのような順序で実行されて、
カスタマイズする際はどのようにやれば目標を達成することができるのか？

固めるだけならcpioでもよいのだが、kernelから実行されるように
固めなければならない。entryはどこか？というのも問題。

再び
ramfs-rootfs-initramfs.txtより抜粋

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


initramfs VIVERの技術

（ブートパラメータの解釈、ハードウェア認識、カーネルモジュールの
ロード、デバイスノードの作成、ネットワークの起動、HDDのマウント

fatboot、liveCDとかほかのdistributionのinitramfsを
cpioであけて見てみるのも一つの方法ですね。

initramfs

initramfs作成支援スクリプト

initramfs-toolsの解説プレゼン

ちょっと違うなぁ・・・
rhel boot-init-shutdonw-process