Re: CASSIOPEIA report

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

鈴木(康)です。
<200005160511.OAA02078@ninja.hpc.bs1.fc.nec.co.jp>の記事において
suz@hpc.bs1.fc.nec.co.jpさんは書きました。


  | 割り込みエントリの vrpmu_intr() から直接 call 関係で処理が
  | 続いていくみたいですね。(config_hook_call() も含めて)
  | 
  | ということは、この間ずっと、ハイレベルな割り込み処理として実行されますね。
  | このレベルでは、sleep することはもとより 同種の割り込みが入るように
  | マスクを開く(eni ?) こともまずそうです。
  | 
  | このレベルでも printf はできるようなので、同じようにして
  | 割り込み処理を一旦 抜けてから、(キューイングされた)実際の処理を行う
  | という構造を導入しないといけないと思います。
  | 
  | 切口としては、やっぱり config_hook_call ではないでしょうか？

ちょっと考えてみたんですが、やっぱり サスペンド/リジュームを
おこなうレベルは、ドライバの probe などを行うのと同じレベルでないと
いけなさそうです。(= sleep ができるレベル)

ということは、割り込み処理じゃなくて カーネルスレッドで動くように
なっていないといけない。

callout は割り込み処理 と同じレベルで動くので、
pcmcia のカーネルスレッドのような実装じゃないといけないんではない
でしょうか？

# もしくは、btnデーモン にいったんイベントを渡して、そこから機能を
# 呼び出す形？ 

----

callout をちょっと見ましたが、次のような構造みたいです。

kern_clock.c の hardclock() から setsoftclock() を呼び出し、
低レベルの ソフトウェア割り込みを登録する。(最適化が入っていて
直接呼び出すこともできる。)

本来どうあるべきかということはおいておいて...

config_hook_call が、 低レベルの ソフトウェア割り込みから呼ばれるような
構造をいれるだけで、実験はできそうな気がします。


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