Re: CASSIOPEIA report

[suz@hpc.bs1.fc.nec.co.jp (Koji Suzuki)]

鈴木(康)です。
<200005161114.UAA26803@shin1.sm.sony.co.jp>の記事において
takemura@netbsd.orgさんは書きました。

  | 
  |  > config_hook_call では、イベントを登録するだけにして、
  |  > config_hook_intr で 実際の call 動作をさせる。
  |  > 
  |  > おおきなメリットがあるわけじゃないんですが...
  |  > 
  |  > config_hook の関数群が動作する割り込みレベルを一定にすることができる。
  |  > 
  |  > ので、なにかと便利だと思うんですが いかがでしょうか？
  | 
  | software interrupt がどういう context で実行されるのか良くわかって
  | いませんが、

NetBSD/hpcmips では、hardware interrupt と同じ context で実行されます。
が、hardware 割り込みの マスクが全くない状態です。

このレベルで実行される割り込み処理は、優先度が低く
すべての hardware interrupt を受け付けることができるもの
と(たぶん)定義されています。

伝統的に timer 処理 と network の処理がこのレベルで動くようです。

割り込みの レベルが重要なのは、いったん (例えば)splimp の実行レベルで
動かし出した intr ルーチンの レベルを splimp より下げることが
できないことに起因します。

  --- レベルを下げると 同種の intr ルーチン が追い越す可能性がある。

したがって、splnet で排他制御されているリソースは、
splimp の実行レベルの intr ルーチンからは 排他制御できないことになります。

  --- splimp で動く割り込み処理は、splnet で動く処理を interrupt
      する。

以上の理由から、タイマー処理は わざわざ software interrupt で実装
されています。

config_hook に関しても、いまの仕様だと splhi 以外で排他制御している
リソースは扱えないという制限があるのだと思います。

# その制限が重要かどうかは分かりませんので、おおきなメリットがある
# とまでは書けませんでした。

  | config_hook を一律にこの仕組みにしてしまうのはちょっと
  | 問題があります。
  | やるとすれば、従来通りの動作と、あとで実行する動作を選択できる
  | ようにするということになります。config_hook_post() とか。
  | あとで考えてみます。

よろしくお願いします。

--
					鈴木　康司 ＠ＮＥＣソリューションズ
					suz@hpc.bs1.fc.nec.co.jp
					TEL 042-333-6465