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

[Naoto Shimazaki <igy@xxxxxxxx>]

At Tue, 16 Mar 2004 21:20:44 +0900,
Yoshihiro Kawabe wrote:
> ただ、今の Linux のカーネルがそうかと言われると引っ掛かるところは色々
> とあります。抽象化が即非効率でないのは明らかですので、結局は設計条件と
> して何をベースにするかと言うことだと思います。
> 
> そういう意味では、LinuxはPC依存の泥臭さがきつい気はしますが。

移植する気のないコードなら、ハードウェアべったりでも特に問題とは
思いませんし、むしろこむつかしい抽象レイヤを導入するデメリットの
方が大きいでしょう。

でも Linux は今では非常にたくさんの CPU とプラットフォームに
移植されているのです。PC 以外のプラットフォームで Linux を
いじってみるとかなり苦痛ですよ。

> でも、昔のSVR(今は知らない)もBSD(こっちも今のは良く知らないので)もそう
> いう部分は多かった(3B2だったり、VAXだったり)様な。

4.4BSD で再設計されました。それが今の NetBSD や OpenBSD の
バスアーキテクチャに引き継がれています。

> どちらかと言うとドライバが呼び出す共通のサービス関数(抽象化レイ
> ヤ含む)の側の話として、呼び出された時の割り込み禁止状態を厳密にしてし
> まうよりも、割り込み禁止時に割り込みの状態を保持/復元を行う方が自由度
> が高いと思いますし、それが悪い設計だとは思えない、ってとこです。

汎用のサービスルーチンでは、大抵の場合むしろ保存/復元式にしなくては
なりません。が、私の先のメールは汎用のサービスルーチンについては
言及していません。

私はあくまでもデバドラの話をしているのです。

デバドラを設計する時、割込禁止時に割込許可状態を保存/復元すると
フェイルセーフになるという考えはほとんど全く役に立たない、
と言っているのです。

保存/復元すると直ちに悪い事が起こる訳ではありませんが、
「保存/復元するとフェイルセーフになる」という「錯覚」は
誤った設計を導く恐れがあります。

錯覚であることを理解しましょう、というのが私の論旨です。


> sleep_on_interruptible()などのLinuxの多くのカーネル内関数は、これをし
> ないで、割り込みの状態を保持/復元せずに明示的に禁止/解除をしているので
> どうかと思いました。

interruptible_sleep_on() は割込許可状態で呼ぶ仕様なのです。
だから、中で明示的に割込許可しても、まあ、間違ってはいません。
また、いずれにしても、スケジューラ(というか最終的にコンテキストを
スイッチするかもしれないカーネルの機能集合)は明示的に割り込みを
許可して良い立場にあります。

// 本当に割り込みを許可するコードは非常に狭い範囲に絞れるとは
// 思いますけどもね。

> Naoto> つまりデバドラの場合は、いずれにしてもコードのどこで割り込みが
> Naoto> 生じ得るのか厳密に管理してドライバを設計する必要があるわけです。
> 
> いえ、その考え方では、やっぱり、Linuxにある様にスケジューラレベルのキュー
> をドライバが直接触るべき、と言う風に聴えてしまうのですが。(まぁ、それ
> が明らかに否定されているわけではないですが。)

Linux においてはまさにその通りです。私が繰り返している、
interruptible_sleep_on() は使わず、wait_event_interruptible() を
使いましょう、というのはそういうことです。

しかし、これは一般論ではなく、Linux に限った話です。
Linux の割り込み周りの設計がダサいから、そうする必要が
あるにすぎません。普通は interruptible_sleep_on() に
見られるような race condition を起こさないように、
スケジューラ I/F の仕様を定めるものです。

> その結果、割り込み禁止に絡まない様なかなり上位の操作を行うところでしか、
> カーネル内の共通関数は使ってはいけないと言う流れになりそうです。

カーネル内のサービスルーチンは必ず呼び出してもよいコンテキストが
規定されるものです。(しばしば undocumented だったりしてナニですが。)

上にも書きましたが、幅広いコンテキストで呼ばれるルーチンが
割り込み状態の保存and禁止と復帰を対で扱うのは必然です。

--
Naoto Shimazaki