[FDclone-users:00905] Re: MINIX3 patch

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

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

> 遅くなってしまいましたがこちらでもこの方法で 3.1.7 と r7716 で動作する
> ことを確認しました。

　取り敢えず手っ取り早い確認手段としては、Xopenpty() の最後
にある safeclose() を削除してみるといいでしょう。本当は後で
どこかで close() してやる必要がありますけど。
　MINIX 3.1.0 でもこの回避策が有効だったので、UNIX 的なお作
法はともかく、MINIX 的にはこれで十分だと思います。


> Xopenpty() が早々と slave を閉じているのを「あれっ？」とは思ったん
> ですが Xlogin_tty() で開き直していたんで納得しちゃってました。
> 一旦 backend にも渡らないといけなかった訳ですか。

　飽くまでも実装レベルでのお話ですが、TIOCSCTTY のある環境で
は、一度 slave として用意された /dev/ttyp? は何度開いたり閉
じたりしても PTY slave として機能します。
　ところが MINIX の実装では、fork() や dup() してどこかで誰
かが /dev/ttyp? を開いたままにしておかないと、/dev/ttyp? は
単なる null device と化してしまうようです。

　FDclone の実装では、PTY slave は子 process が起動して初め
て必要になるので、PTY master だけ backend に持たせておいて、
PTY slave は必要になってから open() させています。
　というのも、PTY master は backend が担うのでまぁいいんです
が、PTY slave は親 process 側で取っておかないと fork() した
子 process に渡せなくて、親が保持するには邪魔なんですよね。
　特に仕事のない backend と違い、親は script 等で user の指
示により file open の機会が多いので、その分 file descriptor
を余剰に残しておきたい訳です。

　今回の MINIX のケースでは、子の使う PTY slave は何も当初用
意した slave やその複製である必要はなくて、/dev/ttyp? を再度
開くことで十分要件を満たせたので何とか対処出来ました。
　しかし、最初の PTY slave そのものを必要とする環境があった
場合は、ちょっと対応が難しくなると思います。Cygwin がちょっ
とそれに近いですね。


> > 　さて、これで MINIX 的に残る問題は /dev/tty 問題だけになり
> > ました。どうにかこれを /dev/ttyp? に関連づけることは出来ませ
> > んかねー。
> 
> 
> std* を全部 redirect されてしまうとどうすれば良いのか分かりませんが、
> 次善の策として stdin を redirect されても stdout か stderr が
> redirect されてなければ動くようにという程度では駄目ですかねぇ。

　基本的に STDIN/ERR は出力用なんで、それを入力に使うのはち
ょっと気持ち悪いですね。取り敢えず MINIX では STDIN の複製を
使うようにしときましょうか。
　less(1) なんかと違って FDclone に STDIN を redirect させな
いとならない理由はありませんから、これで特に弊害は出ないと思
います。ちゃんとエラー終了する訳ですし。

　因みに less(1) は select(2) 使ってないのでこの問題には該当
しません。FDclone は時計表示させたりしてるしねー。top(1) は
しっかり ENOTTY で落ちてくれるのでこれと同じでいいでしょ。


P.S.
　「それは tty ドライバのせいなんだよ。」と思って OSC で本人
捕まえて聞いてみました。「ps 使って見るしかないでしょ。」案
の定。

　因みに、片っ端から tty 開いて試してみた限りでは、自分が持
ち主の tty のうち自分以外の tty は、常に select(2) が ISSET
状態になります。
　なので、持ち主が自分で select(2) が ISSET じゃない tty が
当たりなんですが、その瞬間たまたま user が何かキー入力してた
らアウトですね。

　あと、setsid(2) しない限りは /etc/utmp で見た pid が使えま
すね。普通はこいつは login shell で process group の長になっ
てますから、getpgrp(2) の結果と等しい訳です。
　で、setsid(2) されると process group が代わるばかりか、特
に login を伴わない pty を作られた場合は utmp に載りませんか
ら、screen(1) とかも駄目ですね。

　奥の手として考えた「ユーザに OTP 入力させて tty から読む」
も失敗でした。何と、持ち主が自分である tty からはどれを読ん
でもキー入力が拾えてしまいます。
　ならどれ使ってもいいじゃん、とは思うのですが、ttyp0 の所有
者が ttyp1 からキー拾うとゆーのは、気持ち悪いだけじゃなくて
何か弊害がありそうですよね。

                                               しらい たかし