[linux-users:102289] Re: 組込Linuxドライバの作成方法

[Naoto Shimazaki <igy@xxxxxxxx>]

At Sat, 20 Mar 2004 04:31:37 +0900,
Yoshihiro Kawabe wrote:
> ＃ なんか長く続けすぎてるかしら。

読みたくない人はとっくにフィルタしてると思われ。
つーか、「Linux のデバドラ書いて ROM にねじこんで」なんていう
話題は Linux user の activity に他ならないと思いますから、
よろしいのではないかと。

> Naoto> でも Linux は今では非常にたくさんの CPU とプラットフォームに
> Naoto> 移植されているのです。PC 以外のプラットフォームで Linux を
> Naoto> いじってみるとかなり苦痛ですよ。
> 
> なるほど。SPARC版(SS-2が転がってる)をトライしようと仕掛けたことはあり
> ますが、必要性が無くなってしまってやってません。PA-RISCマシンにも、入
> れようかと画策しているのですが、こちらも急ぐ必要がなく放置です。(と言
> うかもう長いことHP-UXすら起動してないな)

私は去年 ARM 系 CPU のボード用にデバドラを書いたのですが、まあ、
いろいろとなんだなあという所に直面する事たびたび。

> 4.3renoの頃にVM周りがごそっと変わったり、アーキ関係が見通しがよくなっ
> たりしましたね。MachのVMっぽい(と言うかそのもの)って感じが良さげでした
> ね。それをついで、4.4は綺麗になったんでしょうね。

Mach 由来の vm は FreeBSD もですね。NetBSD の vm は更に
別のものに入れ替わってます。これ。

http://www.netbsd.org/Documentation/kernel/uvm.html

> Naoto> 錯覚であることを理解しましょう、というのが私の論旨です。
> 
> いえ、そこでは、特に錯覚はしてないのですが。

まだこのスレッドを読んでいるかもしれない榎田さんや
もしかすると読んでいるかも知れないその他の不特定の
人々を念頭に置いた記述ですので、どうぞお気になさらず。

> Naoto> interruptible_sleep_on() は割込許可状態で呼ぶ仕様なのです。
> 
> 歴史的経緯は知らないのですが、敢えて初めにそう設計したのでしょうかね。
> 単に初期にそうなってしまって引き摺ってるだけってわけではないのですよね？

分かりません。私が最初に Linux のデバドラを書いたのは 2.0 でしたが、
このころ既に『Linux Device Driver』に interruptible_sleep_on() の
問題点が指摘されていました。そのころから 2.4 までデバドラの
I/F は基本的に変わっていません。(2.6 は知らない)

なんとなく、設計ミスじゃないかという気がします。

// src/include/linux/net/sock.h の struct sock の設計も
// 大失敗だと sock.h のコメントに書いてありますが、
// こちらは 2.4 では苦労して移行している最中でした。
// Linux は結構いろいろと設計上のヘマをしてますが、
// ダメな設計を捨ててやりなおすこともまた結構やってますね。

> Naoto> 上にも書きましたが、幅広いコンテキストで呼ばれるルーチンが
> Naoto> 割り込み状態の保存and禁止と復帰を対で扱うのは必然です。
> 
> ですよね。なぜ、その常識だと思っていた(少なくとも、Linux誕生以前、80年
> 代後半に私が観たいくつかのカーネルでは)ことが無視されているのか、興味
> が持てたりしますが。やはり、行き当たりばったり的なものなのでしょうか？

なぜかは知りません。

たしかにおっしゃる通りなんですよね。これまで散々「割り込み禁止/以前の
状態への復帰」に否定的なことを書いて来ましたが、それは「デバドラ内で
それをやっても安全性は向上しない」と言いたいからでした。

実際には、(タスクスイッチの周辺を例外として)カーネルの全域で
「割り込み禁止/以前の状態への復帰」以外の操作を禁じてしまう方が
一般的でしょう。BSD の spl 然りです。そうすればプログラマは
「割り込みを許可すべきか、以前の状態に復帰すべきか」を悩む
必要がありません。前者は許されないからです。プログラマに
必要のない選択を要求しないのは、良い設計です。

しかし Linux はそうなっていない。

割り込みの禁止や許可は非常に細かく頻繁に行われますから、
「以前の状態への復帰」のコストが大きいと性能にひびきます。
性能のためにあえてやるなら、それも理解できます。

ところが今のプロセッサの場合、以前の状態を保存/復帰する
コストは実際非常に小さく済みます。CPU のレジスタか、
せいぜい 1 次キャッシュくらいまでしか消費しません。
しかも Linux の場合、割り込み全体を禁止/解除してますから
CPU の当該レジスタをいじるだけで割り込みコントローラは
触る必要がありません。性能には影響しないでしょう。

私には理由は分かりません。


余談ですが、多重割り込みをサポートしようとすると、割り込み
コントローラを操作せざるを得なくなります。しかし、優先度
(splXX) の操作のたびに割り込みコントローラのレジスタに
アクセスするとはっきりと性能に影響します。そこで、「本当に
割り込まれるまでは割り込みをマスクしたフリをする。割り込まれて
から改めて割り込みコントローラを操作してちゃんとマスクする。」
なんてことをやります。非常に I/O の忙しい環境下では 20% 位
性能に影響したりしますから侮れません。

--
Naoto Shimazaki