[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[plamo:05552] Re: gzipped kernel
-
From:Hiroshi Futami
-
Date:Wed, 29 Mar 2000 10:55:44 +0900
- Subject: [plamo:05552] Re: gzipped kernel
- From: Hiroshi Futami <futami@xxxxxxxxxxxxxx>
- Date: Wed, 29 Mar 2000 10:55:44 +0900
- Posted: Wed, 29 Mar 2000 10:54:29 +0900
ふたみなのです。
# じっくりと調べている訳ではないので、嘘書いてる可能性が高いです :-)
From: KOJIMA Mitsuhiro <kojima@criepi.denken.or.jp>
Subject: [plamo:05535] Re: gzipped kernel
Date: Tue, 28 Mar 2000 09:51:24 +0900
Message-ID: <20000328095052T.kojima@criepi.denken.or.jp>
> > # 金曜日の夕方迄には調べられますけど、遅いですか?
> >
>
> まー、それほど本質的な話ではないので、お手数をかけていただくほどのもの
> ではないです(苦笑)
今、別の目的で勉強しているので、ついでに調べました :-)
MBR が 512 バイトしかないという i386系の制約は同じですけど、
MBR(boot0+スライス情報)
boot1
boot2
/boot/loader
の順に制御が移っていきますが、カーネルが圧縮されている必要はないみたい
です。
# /boot/loader が forth インタープリタを組み込んでいるというのは昨日し
# りました。
「386BSDソースコードの秘密」を見ても、カーネルは圧縮されている必要は
ないようです。ついでに、MINIX 1.5 も調べたけど、こっちはカーネルのサイ
ズが小さいので、圧縮が必要ない可能性はあります。
ただし、Linux の場合はカーネル再構築の際に、大き過ぎると文句を言われ
ますよね。ですから、モジュールでサイズを小さくしたり、bzip2 で小さくす
る必要があります。
HD のサイズも大きくなっているので、インストール後も圧縮したカーネルを
伸長しながら読み込み必然性はあるのか? と思います。ひょっとして、ブート
ローダの制約で、読み込めるカーネルサイズに制限があるということはないで
すか?
# この場合、gzipped kernel は Linux の利点とは言いにくい気がします。
-- ふ
- Follow-Ups
-
- [plamo:05578] Re: gzipped kernel, cyber205
- References
-
- [plamo:05531] gzipped kernel, KOJIMA Mitsuhiro
- [plamo:05534] Re: gzipped kernel, Hiroshi Futami
- [plamo:05535] Re: gzipped kernel, KOJIMA Mitsuhiro
[検索ページ]
[メール一覧]
Plamo ML 公開システム