[FDclone-users:00902] Re: MINIX3 patch

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <20100707021245.9efda8be.riki1017kazu@gmail.com>
        Rikito INAKAZU <riki1017kazu@gmail.com>さんwrites:
> 稲員です。

> WRITE_DIR 対応はどうしても欲しくて実装した訳ではなく、なんとなくやり
> 始めたら出来そうな気がして実際小一時間で出来ちゃったというもので、
> 少しでも詰まるようだったら止めていたと思います。

　手間や難易度の問題ではなくて、既存のコードに不必要に手を加
えることへの危惧を感じています。

　この辺りのコードは OS 依存で手順がバラバラで、手を加えた箇
所がどこに影響を及ぼすかという判断が難しく、全ての環境で動作
確認しないと安全性を保証出来なくなってしまいます。
　勿論、必要性が高ければ多少のリスクもやむを得ないと思います
が、そうでないならいたずらにバグの温床を埋込むことになり兼ね
ませんよね。


> 新規の対応 fs を増やすことの是非そのものは私には判断付きかねますが、
> そもそも最近の fs って今の WRITE_DIR のような algorithm で entry を
> 並べ替えようとすること自体に意味がないんでしたっけ？

　FS の構造上、最近の設計では並び替えがそもそも無理という FS
が増えて来てます。でもそれとはまた別の話として、WRITE_DIR の
無意味さを感じています。

　最近は OS も HDD も速くなったので ls -f 的なことをする機会
が少なくなって来たんです。つまり、directory entry は sort し
てから処理するのが当たり前になりつつあります。
　勿論、user command である ls(1) 自身は従来から sort して使
用されて来たと思いますが、find(1) 的なことは readdir(3) の出
力順をそのまま使用するのが一般的でした。
　しかし、最近は高速化と LL の普及とで sort してから処理とい
う流れが当たり前になりつつあります。となると、WRITE_DIR で並
び順を書換える意味が薄れてしまいますよね。

　依然 directory entry の記述順に処理される機会は無くならな
いとは思いますが、少なくともその順序を気にしなくてはならない
局面は殆んど無いのではないでしょうか？
　仮に WRITE_DIR を機能的に完全に殺したとして、一体どれくら
いの FDclone user が困ることになるんでしょうかね。


> > 　普通の OS なら制御端末を自力で探して /dev/ttyp? を使えばい
> > いんですが、MINIX は job control が死んでるので一般的手法で
> > 制御端末を探せないんですよね。
> 
> 
> 確かに error 吐いて起動できませんね。ただこれはあまり気にしなくてもいいん
> じゃないかと思います。制御端末を自力で探せる環境でも多くの同種のコマンドも
> そこまでしないと思いますし。一方で、

　これですけどそろそろお手上げ状態ですね。対応の /dev/ttyp?
を探す手段を思いつく方はいませんか？今まで試したのは下記のと
おり。

1./etc/ttytab から TTY 一覧を取得して一つずつ持ち主を確認。
  →TIOCGPGRP が常に pid=0 を返すので持ち主不明。
2.TTY 一覧から順に開いて /dev/tty との fstat(2) 比較。
  →当然のことながら一意に同じ項目はなし。
3./dev/tty を開いて ttyname(3) で名前を探す。
　→「/dev/tty」と返ってくる。
4./dev/utmp から稼働中 ttyp を探して login shell pid を取得。
  →login shell と current process の関連性が追えない。
5./dev/mem を読んで制御端末を探す。
  →root 権限が無いと読めない。
6./proc の中から情報を探す。
  →/proc が無い。

　こうなると、最後の手段は「ps(1) 出力を parse」くらいしかな
いんですが、自分の持ち物を他人に教わらないといけないなんて悔
し過ぎるので何とかしたいところです。


> こっちの方はかなりまずいですね。本当に PTYMODE が使いものにならない。
> とはいってもいきなり _NOPTY じゃ偲び無いので週末あたりに調べてみたいと
> 思います。端末周りは良く分かってないので大分かかるかもしれませんが。

　タイミングによっては、稀に子 process 画面が表示されたりは
しますが、その場合でも入力が一切効かないので制御不能です。
　fork(2) の前後に sleep(3) 置いたりしてタイミングを意図的ず
らしてみたりはしてるんですが、どうにも埓が開きませんね。そも
そも TIOCSCTTY も TIOCNOTTY も無いので制御しにくいし。


> それどころか、ここまでやっておいて言うのもなんなんですが FDclone が公式に
> MINIX 対応すること自体に懐疑的だったりします。 MINIX が最終的に何を目指し
> どのレベルまでいくにしても現状ではまだまだ不備の多い環境なのは否めませんから、
> 将来公式に対応するにしても今はまだ時期尚早かなと。

　今回 MINIX に手を出したのは、そもそもの教育用という目的に
配慮したからです。その目的なら初学者が多くて「初心者向き」を
謳った FDclone は打ってつけだろうと。
　でも、後になって色々調べていくと段々マニアの玩具にしか見え
なくなって来てます。

　まぁ、折角色々 MINIX 用に回避識別子を用意したので、それは
それで release に含めとこうと思います。他の環境ではこれらは
全て undef されますし。


P.S.
　RTC が GMT になってないと localtime が狂ってしまうので、そ
んな設定に出来ない VMware 上では結構この縛りがネックになって
ます。普通はどうやって対処するんでしょう？
　私は即座に時刻修正 command 作って /usr/local/etc/rc.d に突
っ込みましたけど、そもそも TZ を無視する readclock(8) が悪い
んですよね。

                                               しらい たかし