Re: CASSIOPEIA report

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

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

  | やっと理解しました。

うまく説明できなくて申し訳ないです。

  | config_hook のイベント処理を software interrupt まで
  | 遅延するのは本質的に callout と全く同じなので、
  | config_hook に機能を追加するのは見送りたいと思います。
  | callout を利用して下さい。
  | 
  | カーネル内に全く同じことをするルーチンや API が
  | 複数あるのはよくないですよね。

callout_xx について私が誤解していなければ(... って自信ないんですが)
本質的な違いはつぎの点になると思います。

	o 最低 1 回の hardclock() イベントが発生しないと実行されない。
		-- 時間的に 間が空く
		-- 割り込みをマスクしていると実行されない

ハードウェアと密接に関係したもの以外では、
この点が気になるケースは、ほとんどないと思います。

しかし、全く同じことをするわけではなく、
今回はそれが引っかかるケースだと思います。

  |  > config_hook に関しても、いまの仕様だと splhi 以外で排他制御している
  |  > リソースは扱えないという制限があるのだと思います。
  | 
  | それは誤解です。config_hook のイベント処理がイベント発信元と
  | おなじ interrupt level で実行されるというだけで、
  | 発信元の level が splhi かどうかは config_hook 機構とは
  | 関係ないのです。

"関係ないので、イベント発信元と イベント受け取る側で interrupt level
に関しての取り決めがないといけない -> 拡張するときに それが足枷に
なって困るのではないか？" という点を指摘したかったのです。

今回以外のケースでは、callout を使えば 確かに足枷は外れるわけですが、
config_hook_call から 受け取るまでの間で interrupt level 変換 
してもらえた方が 嬉しいかも知れません。

-----

とはいえ、実際に困っているのは 実験だけだし、将来的に困るケースも
ないかもしれないので、強く主張するつもりはないです。

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