[plamo:05578] Re: gzipped kernel

[cyber205]

> # /boot/loader が forth インタープリタを組み込んでいるというのは昨日し
> # りました。

ありゃま…。FORTHっていろんな所で見ますね。
でもこれは案外ファームウェア代わりなのではないかなとも思います…。

というのも、実は、先日まで情報収集していたOpenBIOSなんか、
中身はそのまんまFORTHインタプリタだったりしますので。
＃ これはx86系マザーボードのBIOS-ROMに入れ換えて実装します。
＃ 最近、これでx86CPUを積んだマザーからLinuxの起動に成功したらしいです。

いちお、OpenFirmwareというIEEEの規格があるようで、AppleのPowerMacシリーズや
SUNのSparcStationなどのBIOS(Firmware)はこれを積んでいるらしいですよ。
AlphaのファームウェアもFORTHインタプリタを搭載しているという話ですが、
多分これに準拠しているのだと思います。

>  ただし、Linux の場合はカーネル再構築の際に、大き過ぎると文句を言われ
> ますよね。ですから、モジュールでサイズを小さくしたり、bzip2 で小さくす
> る必要があります。

bzliloはbzip2を使っているからbzliloだというわけではないようです。
どうもカーネルのローディングにもう１段かましてあるため、
カーネル最大サイズ制限がなくなっている(緩和されている？)起動方式みたいですよ。
ノートコン等で起動できなくなるトラブルも結構あるみたいですが…。

>  HD のサイズも大きくなっているので、インストール後も圧縮したカーネルを
> 伸長しながら読み込み必然性はあるのか? と思います。ひょっとして、ブート
> ローダの制約で、読み込めるカーネルサイズに制限があるということはないで
> すか?

まったくその通りです。
既存のBIOSからブートする場合、Linuxにも「640KBのカベ」が存在します。

どうしてそうなるのかと言いますと、
まず、３２ビットプロテクトモードに移行する前の、x86系CPUがアクセス可能な
メモリ範囲は、初代8086との互換性を守って最大1MBに制限されています。
(いわゆる16ビットリアルモード。80286以降は64KBほどおまけがつくらしい…)

このうち、A0000H〜FFFFFHまでの上位384KBはVRAM、BIOS、拡張ROM等が使いますので、
実質的に利用できるのはDOSの時代に「コンベンショナルメモリ」として知られた
640KBそこそこの領域しかありません。

基本的にAT互換機のDISKBIOS(INT13H)はプロテクトモードに対応しておらず、
これだけを使ってカーネルを読み込み、展開する場合には32ビットOSのLinuxでも
「最大カーネルサイズ640KB」の壁が存在します。
＃ APMBIOS等の比較的新しいBIOSは違いますが、DISKBIOSを含む古いBIOSコールは
＃ 16ビットリアルモードからの利用が前提となっていて、
＃ 32ビットプロテクトモードでの呼び出しに対応できません。

通常の起動方法ではスタートアップ後、gzip展開コードを含んだLinux圧縮カーネル
(vmlinuz)を、16ビットモードのまま、既存のDISKBIOSを使ってまるごと
メモリの下位640KBに読み込んでおき、読み込んだvmlinuzを起動します。
するとvmlinuzにあるgzip展開ルーチン部分は、下位640KB領域のその場所から
すぐ32ビットモードに移行して、メモリの下位１ＭＢより上にある、
プロテクト領域で扱えるメモリ領域へカーネルを展開し、
その後Linuxカーネルに制御が移ってカーネルが動き出すという仕組みになっています。
＃ そういうわけで、gzip展開ルーチン等の追加によりKernelサイズは
＃ 640KBよりさらに少ない「圧縮状態で最大508KB」にまで制限されます。

bzliloの場合、まず最初にBIOSから読み込まれるスタートアップコード中で、
カーネルをHDDから読み込む前に、いきなり３２ビットプロテクトモードに移行し、
広いメモリ空間を自由に扱えるようにしておいてから、大きなカーネルを読み込む
設計だったはずで、このため、３２ビットモードでCPUを動かしていることから
カーネルの読み込み時、単純にDISKBIOSコールを使って読み込む方法が使えません。
＃ 多分、このあたりがbzliloだと起動できなくなる原因だと思います。