Linuxプログラミングインターフェイスから
疑似端末に関する重要な点は、スレーブデバイスが標準端末と同じように見えることです。端末デバイスに適用できるすべての操作は、疑似端末スレーブデバイスにも適用できます。これらの操作の一部は、疑似端末にとって意味がありません(たとえば、端末回線の速度やパリティの設定)が、疑似端末スレーブがそれらを黙って無視するため、問題ありません。
スレーブデバイスは、端末指向プログラムの標準端末のように見えます。さらに、端末から発信されたプログラムのプロセスに対する制御端末のようなものです。
マスターデバイスは、ドライバープログラムの標準端末のように見えますか?はいの場合、制御端末のように?いいえの場合、デバイスファイルや通常のファイルのようなものですが、必ずしも端末のデバイスファイルである必要はありませんか?
ありがとう。
マスターデバイスは端末デバイスファイルのように見え、tcgetattr()
/tcsetattr()
/&cを介してアクセスできるラインディシプリンを備えています。 isatty()
からの成功結果。実際、これはスレーブデバイスと同じラインディシプリンインスタンスであり、これがマスター側のプログラムがウィンドウサイズの変更などを送信する方法です。スレーブ側のプログラム。これは、回線速度をゼロに設定し、それによって回線規律のハングアップメカニズムをトリガーすることによって、マスター側プログラムが(エミュレートされた)モデムハングアップを通知する方法でもあります。 (したがって、テキストが回線速度について述べていることは正しくありません。は回線速度が意味のある場合です。)
違いは、読み取り/書き込みI/Oにあります。読み取られるのは、実際の端末の場合、実際の基盤となるシリアルデバイスを介して送信される文字のシーケンスです。書き込まれるのは、実際の端末の場合、実際の基盤となるシリアルデバイスが受信する文字のシーケンスです。言い換えれば、それは、ライン分野による正規/非正規の入出力処理の反対側です。
これには複雑さがあります。つまり、パケットモードとリモートモードです。後者はそれ以来ずっと死法に陥っており、今世紀の初めでさえほとんどのオペレーティングシステムに存在していなかったため、ダニエルJ.バーンスタインの古いptyツールへのパッチが必要でした。前者はほとんどのタスクで特に役立つわけではないので、この回答では詳しく説明しません。
マスターデバイスは通常、マスター側プロセスが実行されるセッションの制御端末ではありません。これは、概念的には、実際の端末の内部に類似したものを間違った場所に置くことになるでしょう。このようなセッションの制御端末は、存在する場合は、別の端末です。
これは、script
、NeoVIMの:terminal
、emacs、およびptybandage
(パイプラインの一部でない場合)などのプログラムの場合であり、これらは別の端末デバイスに直接レンダリングされ、その端末デバイスによって制御される対話型セッション内で実行されます。
SSHサーバー、GUIターミナルエミュレーター、 console-terminal-emulator
noshツールセット、ptyrun
(通常の使用法)、またはモノリシックフレームバッファーターミナルエミュレーターなどには当てはまりません。 zhconとして。これらは、console-terminal-emulator
の場合のファイルシステム内のバッファーやFIFOからTCPソケットからフレームバッファーやHIDクラスのデバイスまで、あらゆる種類の異なるI/Oデバイスにレンダリングされます。さらに、console-terminal-emulator
、SSHサーバー、およびフレームバッファー端末エミュレーターは、通常、セッションを開始するための制御端末がないデーモンコンテキストで呼び出されます。
この図は決定的なものではないことに注意してください。マスター側プロセスがスレーブ側プロセスをフォークするわけではありません。たとえば、nosh-toolsetユーザースペース仮想端末では、スレーブ側のプロセスはサービスマネージャーによってフォークされた通常のttylogin@*
サービスであり、マスター側のエミュレータープロセスとスレーブ側のログインセッションプロセス。しかし、それはこの答えの範囲を超えています。
マスターデバイスはほとんどパイプのように見えます。ファイル記述子は、パイプのように、都合のよいサイズで読み書きできます。短い読み取りが発生するため、read(2)が何を返すかを常に確認してください。