[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[plamo:29794] Re: udev and /dev/cdrom, /dev/dvd, etc..



本多です

これもえらく長くなってしまいました。収束の為に後半にこのreplyとは別に今回の
議論の元でのまとめもどきを書いておきます。

> 私が勘違いしているのかも知れませんが、initrd は関係ないんじゃないでしょうか。
はい。この点は前の反省メールで書いたとおり同意です。

> /dev は tmpfs でマウントされるので、Plamo も他のディストリビューションも
> 一からデバイスノードを作成していくのは同じだと思います。

ええと、問題はtmpfsでmountする前の/devの状態です。つまり、fsckをudevの前
(==tmpfs mountの前)にもってこれるかという可能性について論じたつもりです。
*もし大本の/dev (tmpfs前)にrootfs関係のdevice fileが存在するならばfaskを前にもってこれます。
*もし大本の/devが空に準ずる状態ならばfsckを前にはもってこれません。

> 書き換えたくない場合を想定しているんですかね?

ええ、これも理由かもしれません。
あとudevの設計理想からdevice filesをstaticに作成するのを極力
なくするというのもあるかもしれません。こうしておけば、どのような
file systemがroot fsで来ても対応できますし、変更にも柔軟ですよね。

-------さてとりあえずまとめの提案------------------------------
まず、"/etc/udev/rule.d/70-*に情報を反映させるというのは"良いと思われます。

*方法ですが、debian他のコピー方式が良いと思われます。

なぜならplamoではudevの起動前(tmpfs mount前)の/devに必要なdevice filesを
installerが作成していますが、これらのfilesが存在する必然性がない(ここが私が勘違いした点)
からです。 将来的にその存在が保証されない。

*rc.Sにおけるcopybackの位置ですが

オリジナルは
A) procfs,sysfs mount
B) /devにtmpfs mount
C) /devにstatic devices(/dev/console,null等)を作成
D) udev 起動
E) (modprobeを連続実行しmodules load + sleep 1) 3 sets
F) swap on
G) fsck
H) rootfsのread write remount

私としては E)を一旦削除。 H)の後にcopyback。その後にE)を追加。
が良いと思えます。
とりあえず、E)を先に実行すると遅延されたkernel eventが何時来るか判らないので
write remountとcopybackの間に不整合の可能性があるからです。まああ、でも、
あまり神経質でなくとも良いですけど。

--------------------------------------------------------------------------


Follow-Ups
[plamo:29795] Re: udev and /dev/cdrom, /dev/dvd, etc.., Naofumi Honda
[plamo:29796] Re: udev and /dev/cdrom, /dev/dvd, etc.., KOJIMA Mitsuhiro

[検索ページ] [メール一覧]
Plamo ML 公開システム