新規記事投稿

フォロー記事投稿

記事のキャンセル

物心がついたころには、すでに遅く、ハードウェアは、こともあろうに、
デバイスという形で、ファイルシステムの中に組み込まれてしまってい
たのだった。

そもそも、んなモンの中に押し込めて、十派ひとからげで取りまとめて
しまうことに、かんなり無理があるにも関わらず、そこへ押し込んだ当
の連中は、統一された操作が美しい、などとヌかしておる。

ならば、あのとってつけたような I/O CONTROL とか言う機構は、何ぞ。
キョ〜〜ビのシステムでは、スマートとは言えんし、不恰好ではないか。
さらには、とても遅い。



近頃の OS では、 I/O CONTROL の手続きを経てハードウェアを制御す
ることは、カーネル空間とユーザ空間の行き来となってしまうため、か
なりのオーバーヘッドがある。

手持ちのマシンを使って Linux ( Kernel 2.0.36 )で試したところで
は、中身の無い ioctl コール( つまり、デバイスドライバ内では何も
せず、即、リターンする )で、約 1.7 マイクロ秒も、かかる。

これは、同一ユーザ空間内の C の空( カラ )関数コールが、 十数ナノ
秒で終わることを考えれば、100 倍近くの時間だ。


さらに、 I/O CONTROL を扱うにしても、入力や出力の区別があって、
然るべきであるのに、なんと ioctl() 関数自体には、その区別が提供
されていない。このあたりの融通が利くように自前でなんとかしようと
して、適当にメモリ管理をして ... 、などとモガくと、あっと言う間
に、 5 〜 6 マイクロ秒を消費してしまう。

こうなると、もう、論外、場外、国外退去。マイクロ秒オーダなんての
は、ハエが止まる。



同じ PC で、手持ちの PCI ボードから 1 バイトをポート入力すると、

      DOS    ( マシン語で直接入力 ) : 約 1.0 マイクロ秒
      Win-NT ( カーネル提供の関数 ) : 約 1.3 マイクロ秒
      Linux  ( インライン展開関数 ) : 約 1.4 マイクロ秒

といった感じで、一般に遅いとされるポートの入出力の処理においてさ
え、 I/O CONTROL は、充分にオーバーヘッドを生むと、考えられる。



 I/O CONTROL なんぞは、今となっては、先人の知恵というよりも、前
世紀の遺物、恐竜の化石。で、ユーザ空間に対して、何か、他の、新し
い、今風の機構は、提供されないものだろうか？

仮称 Direct Interrupt とか、Direct DMA とかさ。

 Win-NT にせよ、 Linux にせよ、ドライバ書きが、力づくで、メモリ
空間に風穴を開けるぐらいしか手が無い、では、キョ〜ビのカーネル様
としても、あまりに芸が無い、と思うんだけどなぁ。




以下は、参考まで。

      
 Linux の場合は、root 権限があれば、アプリ内で、直接ポート操作も
可能であるが、実測では、

      inb()  .... 約 1.46 〜 1.5  マイクロ秒
      outb() .... 約 1.5  〜 1.65 マイクロ秒

であり、カーネルモードのドライバよりも処理は遅くなる。


 Win-NT と Linux はカーネル空間内のドライバでポート入力を行った
ものだが、ハードウェアの仮想化( 抽象化 )が Linux よりも幾分進ん
でいると思われる NT の方が、なぜか、成績が良い、というのは、ちと、
興味深い。