[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FDclone-users:00901] Re: MINIX3 patch
- Subject: [FDclone-users:00901] Re: MINIX3 patch
- From: Rikito INAKAZU <riki1017kazu@gmail.com>
- Date: Wed, 7 Jul 2010 02:12:45 +0900
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;d=gmail.com; s=gamma;h=domainkey-signature:received:received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding;bh=/xpc064r7FvFAdoFRu39qFL9L7E46uSg1qlobZuveA0=;b=hoempMb2sFs3Eo4YE9XR5EEl+DDWfz814rY9YDbbg3TyK4cMcr3hO1oIeSPyaeh7ZpyX78LBrw/wmaxB6nS28rb5WrqKlsmKS6qOR2AoL86x87KYOHVGgH9xjxVNVr5IIUe3YM83kSI6s0w2SI4dxdPr2PEcjR3cbJUeM7ppfZg=
- Domainkey-signature: a=rsa-sha1; c=nofws;d=gmail.com; s=gamma;h=date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding;b=Dbj061lEMJBHhesiaNtQ1S468kgxbbt4jO9+T26IiIN1VPp9z+BZFpX8qN0Q2M0HzBC5nf8oR5AiVBLPF4H0wluX4vH9nAFD7kCPVPI6xkTx5j574ISQIZPdiwoUL//zM9ZqBEEP5gEQFeAypsiRjeExIPlz9SaaYRAm6PkQ/g0=
稲員です。
On Tue, 06 Jul 2010 02:11:06 +0900
Takashi SHIRAI <shirai@unixusers.net> wrote:
> WRITE_DIR は最早時代遅れの機能のような気がしてるので、今更
> 新規に対応 file system を増やす必要があるのかどうか疑問なん
> ですけど如何なもんでしょう?
WRITE_DIR 対応はどうしても欲しくて実装した訳ではなく、なんとなくやり
始めたら出来そうな気がして実際小一時間で出来ちゃったというもので、
少しでも詰まるようだったら止めていたと思います。
新規の対応 fs を増やすことの是非そのものは私には判断付きかねますが、
そもそも最近の fs って今の WRITE_DIR のような algorithm で entry を
並べ替えようとすること自体に意味がないんでしたっけ?
まぁそれはさておき、少なくとも MINIX fs 対応に関する限り MINIX で
使う場合を除けば全く無意味だと考えます。あれを mount できるのは
MINIX 自身と昔の誼で Linux くらいだし、その他の環境では binary size
を増やすだけの dead code になってしまいますし、その Linux にしても
MINIX fs を使うのは MINIX user が何かの作業のためという気がします。
そんな訳で私としても元より MINIX でのみ有効になるよう ifdef でバリア
するつもりでした。先の patch でそうなっていなかったので誤解をあたえて
しまったかもしれませんが。
実を言えば普段の環境では WRITE_DIR は全然使ってなくて常に WRITEFS=2
なんですよ。 0 は言うに及ばず 1 でも 'q' と押し間違えてイラッとして
しまうんで。今回のことで恐らく数年ぶりに使いました。
> 一つは select(2) が /dev/tty 非対応なこと。普通は STDIN を
> 見ればいいんですが標準入出力を redirect されると端末が判らな
> くなるので /dev/tty を使うしかないんですよ。
> /dev/ttyp? や /dev/console は対応してるんですが、/dev/tty
> は major 番号が異なるんで select(2) 側で reject してくれてま
> す。
> 具体的にはどうなるかと言うと、STDIN を redirect して起動す
> ると異常終了しますね。入力が拾えないんで実行不能です。まぁ現
> 実的には特に支障ないかも知れませんが。
> 普通の OS なら制御端末を自力で探して /dev/ttyp? を使えばい
> いんですが、MINIX は job control が死んでるので一般的手法で
> 制御端末を探せないんですよね。
確かに error 吐いて起動できませんね。ただこれはあまり気にしなくてもいいん
じゃないかと思います。制御端末を自力で探せる環境でも多くの同種のコマンドも
そこまでしないと思いますし。一方で、
> あと、疑似端末がうまく機能しません。子 process の出力を親
> が受取るところで、select(2) は入力を検知してるのに読みに行く
> と 1byte も読めないので freeze したようになります。
> PTYMENUKEY の入力により強制終了出来るので致命的なことには
> なりませんが、使いものにならないなら疑似端末機能を殺すしかな
> いですね。
> pty.c を色々いじると突然機能し始めたりするので、cc の bug
> なんじゃないかという気がしてます。その「色々」に関しては、ま
> た const が怪しそうな感じですね。
こっちの方はかなりまずいですね。本当に PTYMODE が使いものにならない。
とはいってもいきなり _NOPTY じゃ偲び無いので週末あたりに調べてみたいと
思います。端末周りは良く分かってないので大分かかるかもしれませんが。
> これね、file system の名称が「1」とか「2」とかだけなので、
> identifier としては弱いと思うんですよ。どっかで重複名称が生
> じそう。
> 一応 Linux 辺りで MINIX file system を mount 出来るようで
> すけど、その場合は「minix」という名称で見せてるみたいです。
> これだと 1/2/3 の区別がつきませんね。
私も最初はなに考えてこんな名前付けたのかと思いましたが、よくよく考えてみると
意外と熟慮の結果のようにも思えるんですよ。なぜかというと MINIX fs なんて
どう考えても実用に供するものと考えていたとは思えない訳で、とすると他の実用 fs
で使われそうな名前空間を徹底的に避けた結果この一見馬鹿げた名前になったと。
考え無しの最悪ケースとしては "mfs" なんて可能性も有り得た訳ですしね。
好意的な解釈すぎますかねぇ?
それに 1/2/3 なんて名前、馬鹿げすぎていて逆に他と被りようがないとも言えます。
むしろ Linux のように違うものを一律同名にされちゃう方がやっかいですね。
もっとも MINIX fs v1/v2 って同名でも昔と今では file system layout が
違ったりするみたいですけど。
なんにしても v1/v2 の WRITE_DIR 対応はしないと思います。
> 実装するにしても、MINIX でのみ対応という形にしておいた方が
> 無難な気がします。
これは前述のように当初からその予定でしたのでご心配なく。
それどころか、ここまでやっておいて言うのもなんなんですが FDclone が公式に
MINIX 対応すること自体に懐疑的だったりします。 MINIX が最終的に何を目指し
どのレベルまでいくにしても現状ではまだまだ不備の多い環境なのは否めませんから、
将来公式に対応するにしても今はまだ時期尚早かなと。
--
Rikito INAKAZU (稲員力士) <riki1017kazu@gmail.com>