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

[Yoshihiro Kawabe <ripula@xxxxxxxxxxxxxxx>]

川辺と申します。

>>>>> "Naoto" == Naoto Shimazaki <igy@xxxxxxxx> writes:

Naoto> PC では ISA の I/O サイクルになりますが、ARM では memory mapped
Naoto> I/O デバイスに対するアクセスになる、などです。マクロのトリックを
Naoto> 駆使して実現しています。

そうですね。この手の書き方は悪くないと思います。

Naoto> 抽象化レイヤに抽象的な見てくれを与えるよりも、既存のデバドラを
Naoto> そのままマルチアーキテクチャ化する方を選んだ結果でしょう。

元がバリバリPC(/AT)だったから、それはそれで自然な流れなんでしょうね。

＃ S390版にもin/outのマクロがあったりするのを観るとなんか微笑ましくなって
＃ しまう。(S3[67]0と違って、ほとんど Memory Mapped I/O になってるのにちょっ
＃ と驚いた。)

Naoto> それは BSD の splxx() でも同じです。spl0() などとして低い優先レベルを
Naoto> 設定する(割り込みを許可する)コードはデバドラ内でも書けてしまいます。
Naoto> もちろん、そんなことをすればカーネルはちゃんと動きません。

確かに、いきなり、spl0()は問題ありまくりですね。
悩ましいのが splimp() とかだったと思います。SVR系だとsplstr()とか
spltty()が微妙なレベルでしたね。
まぁ、ほとんどの場合には、splhi()とsplx()の組合わせだけで考えるのが賢
明って感じでしたが。

Naoto> splxx() で優先レベルを下げて良い(割り込みを許可して良い) のは
Naoto> スケジューラだけで、デバドラは「優先レベルを上げる(割り込みを
Naoto> 禁止する)」と「元に戻す」しか許されません。

はい。そうやるのが変な制限を課さない素直な実装になると思います。

Naoto> 以前の割り込みが許可状態だとコンパイル時に分かっている場所なら、
Naoto> spin_unlock_irq() を実行して良いはずです。そうでない場所で使うのは
Naoto> 間違ったコードですね。

結局、それらがそこかしこにあることも先の問題を呼んでいるのではないかと
思います。が、BSDは未だ良かったのですが、SVR系なんかはとにかく面倒がっ
て割り込み禁止区間を平気で広く取っていたりする実装が多く(プロセスの延
長で明らかにプロセス固有の個所しか触っていないにも関わらず)応答性の低
下を生んでいる気がしました。

Naoto> spl も同様です。splxx() は必ずその時の優先レベルより高い
Naoto> 優先レベルを指定しなくてはならないのですから、「優先レベルが
Naoto> 実行時でないと分からないような箇所では splxx() してはいけない」
Naoto> ということになります。

そこら辺を素直に考えると結局は、前の状態を保持して割り込みを禁止にする
と言う操作と保存した状態を復元する操作の組みをカーネルの標準としておく
のが綺麗なんじゃないかと思いますね。で、スケジューラの最下層では、単純
に割り込みを解除すると。(コンテキストスイッチの辺りでそうすればいいっ
てことだと思いますが。)
--------
  Kawabe,Yoshihiro <ripula@xxxxxxxxxxxxxxx>
  Who is calling me from where?
  Knock on my shell and my mind? from Pearl song.