2009年12月アーカイブ



木工部屋も大掃除。ブルーシート外してきっちり掃除。ガラっとした和室は旅
行気分。

部屋もまた大掃除。ここまで掃除を済ませて新年を向かえるのは人生初だ。

FF13続き。7章のホープの家で黙々とCP稼ぎ。ファング10000を目標にした。ファ ングは威勢がよくていいな。ライトさん、ファングのダブルアタッカーは気持 ちがいい。

そして8章。ここは時計塔の最後のセーブポイントの近くにツヴェルクx5が沸くの でセーブ→タイトルでCPを稼げる。一回CP640でターンに2分弱なので、自給2万弱 可能だ。ここで、ヴァニラとサッズの全ジョブを上げきった。
この場所だと、森から海岸に抜けた頃のサッズ&ヴァニラ組の戦闘時の掛け合いもない。黙々と戦闘をこなすだけだ。

9章に入ったところでCPはこのくらい。32000CP稼いだ。これでもファングは全ジョブ上げれない。他のキャラは全ジョブ上げて、ライト2766,ホープ3405,スノウ9350余る。




さて棚板は。ラワン材。30〜40年もの。昔、東南アジアを乱伐してた頃の材木
だ。今となっては珍しいのでなんとなくとっておいたのだけど、使ってしまい
ます。



棚板は真鍮の飾り釘で固定しました。足りない部分はSPFで。ラワンは色合いが 難しいから、ここで使ってしまって正解だったかな。
これで端材の山もかなり減って一安心。

押し入れにセット。収納力アップ。

FF13は7章まで。6章のこのあたりは綺麗だったな。こんなところで狩りがした い。FF14が楽しみだ。
6章あたりから敵が固い。5章までは、何度もマップを往 復してたりしてたのだけど、一度通るのがやっとだ。
オートクリップは更新された時点で読まないとだめ。ゲームの中では語られな い重要な設定が書いてあったりする。




端材を黙々と製材して、整理棚に。当初、カカッとコーススレッドで組み上げようと思ったのだけど、無駄にホゾ組み。

これでかなりの端材が処理できた。杉、赤松、椹、SPF、集成材、なんでもあり。

今日はここまで。また適当な端材から棚板をつけます。

FF13は6章まで。5章のCP稼げるところで稼いでいたら6章に入っるところでCPの ストック8000弱。一気にアビリティを上げてもまだ4000弱残ってる。ちなみに セーブして、タイトルに戻ってまたロードしてもリポップする。この時間、40 秒程度なので、セーブポイントの近くで稼げそうならどこでも稼げる。あとラ イトさんがいる時が一番の稼ぎ時だ。



久々に木工。買ったまま放置となっていたOneidaのDust Deputyの出番。試しに
換気用のシロッコファンにつなげてみました。しかしこれは口径がφ50まで絞
られてしまうので、吸引力が足りない。自作サイクロンは口径がφ100なのでシ
ロッコファン接続でもそこそこいけたのだけど。



無難に掃除機に接続。分離は完璧。掃除が楽しくなってしまうくらいだ。室内 排気につけたシロッコファンで、部屋外への粉塵が飛ぶこともないし、なんと いっても、切断後の木の芳香(かなりきつい)がすぐに消えるのがいい。>快適快 適。

今日はこんなのを作りました。無駄にアラレ組み。しばらく木工してなかった のでちょっとナマったかな。細部残念な出来。仕上げはセラックで。

これはここに設置。プリンタの上にオーディオアンプを載せる台です。

そうこうしてるうちに、おとといAmazonに注文した"iiyama 23.6インチワイド 液晶ディスプレイ 1920×1080(フルHD1080P)対応 3系統入力装備 マーベルブラッ ク PLB2409HDS-B1"が届いた。やっぱ大きいな。これをメインモニタにも使おう かと思ったのだけれど、1920x1080以外だと拡大表示になるので表示が汚ない。 マイデスクトップマシンはPoweredge T105なので難しい相談だ。ということで 以前のモニタと併用することになってしまい、なにかとても残念な状態に。

さすがに綺麗だ。内蔵スピーカーも、結構いい。これが20800円だもんな〜。




大掃除。今日はリアルデスクトップ環境の整備。なんとなく床からタコ足でとっ
ていたりした電源を、簡単にとれるように。ハブも使い易い位置に固定。

なんとなくそこらに置いて使っていたPS2もきっちり収納。隣りにPS3も。PS2は ヴァナの終焉を見届ける用に。LSの人は一人一人去っていき、春先から誰もい ません。レベルシンクや錬成と、EQ2っぽい要素が増えた。けれど、ここまで来 ても全体のシステムとしてはEQ2には及ばない。しかしなんでEQ2がだめだった かというと、EQ1が廃ゲーだったの対し、EQ2はその反対、廃っぽい要素を全て 排除した。その結果、ソロでもそこそこ遊べるので、みんなで一緒にやってい るオフゲーみたいになってしまったことかな。 あと、モーションが悪かった。エモートの類いは何十種類もあるのに、「走る」 「剣を振る」のモーションが悪い。エモートなんていいから、いつも見るモー ションに重点を置いて欲しかった。そしてテクスチャがお粗末だった。システ ムがよかっただけに残念だった。その点でFF11はとてもうまくやっている。
FF13はというと、三章までならパパッとやれそうなので一からやり直しました。 二時間ちょっとで三章に。もう一度やってみると、勝手に頭の中でストーリー を改変してたことに気付いた。語り部は全てヴァニラだ。ホープ登場の時、隣 にいたのはヴァニラだった。
HDMIのいいモニタでやるのと、家のしょぼいモニタでやるのとでは随分と違う ものだとわかった。認めたくはないけれど感動の量が違う。

なんとなくそこらに転がっている状態のコントローラにもホルダを用意してみ ました。



機能のロガーデータ。一本目の最初のラップなのでほとんどナラシラップ。

赤がスピード、緑がP-LAPの磁石位置。青がフロントにつけた測距センサ。 測距センサの値はフォークが沈んで値が高くなります。 ソフト側でのノイズ処理は入れてません。
加速度計のデータはどうもおかしくて考え中。
そこそこ値はとれてるかな。赤丸をしたところが気になる。このあたりは、ア クセルオフのままブレーキもかけてない状態があるのだけど、そうなのか、測 距センサの値と実際の距離との補正をしないと。
1ヘアのフォークの戻りが謎だな。1コーナー、2ヘアは立ち上がりまで沈んで いるのに、1ヘアは進入から戻りに入ってる。
もっとデータがとりたい。

さんざ迷ったあげくPS3買いました。
セーブデータをUSBメモリに落としてきてみたら、コピーのセーブデータだとプ レイはできてもそれから先のセーブはできないと...。どうもバックアップユー ティリティで移行しないといけなかったみたいだ...。

そして、うちのモニタじゃ、文字が読めたもんじゃない。8x8フォントを読むの に近い苦痛。
小さいHDMI対応のモニタを探すも大きいのばっかりだし。置く場所がない。

困った。


筑波に行ってきました。RS125です。

久々に早起きすると辛い。7時前に筑波に着くと眠さの絶頂。一時間程爆睡。 乗り慣れたNFとはいえ、今日はRS125。ちょっと緊張。
9:30の一本目。気温は10℃あるので十分いける。ロガーもきちんと液晶表示し ている。視認性もそう悪くない。が、8周目を最後にラップの更新がなくなって しまう。経過時間バーは動いてるので、これはたぶんSDカードの配線がもげた。
しかし、E/Gが違うだけでこうも変わるものかと驚く。乗りにくい。スロットル のスプリングが重いのと、スロットル開度が大きいのが辛い。体もナマってる し。動くのが辛いぞ。わたわたしているうちに終了。

二本目は11:00、14℃近くまで上がって、この時期にしては最高のコンディショ ン。ちょうど同じくらいのタイムの人が前に走っていて、いい感じで集中して 走れた。だんだん雰囲気がのめてきたけれど、どうもしっくり来ないな。途中、 手が痺れて握力がなくなってしまいピットイン。ベストで6.5。このくらいのタ イムをCR85で出したいものだ。
16:37だと、バックストレッチでほんのちょっと6速に入るだけ。ホームストレッ チもちょっと5速に入るだけ。1コーナ、1ヘア、2ヘアは1速、ダンロップは2速、 最終は4速か。1コーナー1速っておかしくないか? 確かにちょっとショートだっ たような記憶も。
もつ定もうまいし、いい走り納めでした。

ホームジョイ本田で、木材と灯油をドカ買いして帰宅。年末だからか、車が多 い。至るところで事故だ。久々に首都高で渋滞にはまった。そう、みんな無理 してETCレーンに並んでいるけれど、一般レーンでETCカードを係員に渡しても いいんだよ。中の機械で処理してくれます。
9:20 晴 -162m, 10.6℃, 47.0%, 1016.1hPa
1.8/1.8
6l (5+1(av))EVOREX R2 30:1 残2.5l
Final 16:36
4枚65℃

10:50晴 -43m, 13.7℃, 41.9%, 1015.4hPa
4.5l(2.5+ (1+1(av)))EVOREX R2 30:1
Final 16:36
3枚60℃

1'35.987
1'11.666
1' 7.784
1' 7.477
1' 6.892
1' 7.038
1' 7.036
1' 6.874
1' 6.768
1' 6.764
1' 6.556
1' 7.237
1' 7.146
1'14.165
4' 5.616
1' 6.845
1' 6.728
1' 6.555
1' 6.522
1' 7.019



菜園状況。ニンジンを収穫しました。今年は成功。やっぱり土が大切なんだな。
ニンジンは種蒔いて、そのままです。一番、お気楽かも。



そして部屋の大掃除。送風機をセットして、部屋ごとエアブローして埃を落と しました。エアコンの外面パネルも取り外して洗浄。フィンにつまった埃も歯 ブラシで掻き出し。後はひたすら拭き掃除。
なんとか掃除は終了。次は整理をしないと。
掃除している最中にでてきたこれ、やる夫!? 後を見ると"1971 The Pillsbury Company Minneapolis. Minn."とある。ググってみたところ、アメリカは1869年 創業のパン、ケーキの生地を扱うPillsbury社(http://www.pillsbury.com/)の 1965年からのマスコットキャラクターで、"DOUGHBOY"、向こうじゃほとんどの 人が知っているらしい。知らなかった。これは71モデルということか。最近のは ずっと垢抜けている。
本名はPoppin'Fresh。パン生地の妖精だ。





FF13続き。今日はやっと三章に入りました。三章でやっと全員集合。バトルシ
ステムもオプティマが使えるようになり、ステータスの割り振りも可能になっ
てシステムが見えてきた。ここまで4時間弱。

しかし、もともとアクション苦手なので、難しいです...。レベル制じゃないの がこの先不安。レベル制なら下手さをレベルでカバーできるのだけど。
途中のムービーやイベント、見過ごしてしまいそうな部分があるのがきついか な。「そういえばあそこどうだったっけ...」とニコ動を調べるも肝心な部分が なかったり。
ここまでくると「パルスのファルシのルシがコクーンでパージ」が別になんと も思わなくなります。よくよく思えばいつもこんなことを読んでいるような気 がする。「プロセッサはスーパーバイザモードではレジスタやインストラクショ ンを含む全てのリソースがアクセス可能です」
ここまでの僕の妄想では、(コメントアウト)
ひやかし程度に買ってみたけどちょっといいかも。まだまだやる気十分。



FF13は普通にスルーするつもりだったのだけど、評判やらニコ動見てみたら、
これは評価してみてもいいかもしれないな...。と思い買ってみました。


今日は一章を終わったとこまで。HDMIのモニタで見ると、その映像に度肝を抜 かれる。一時間もすれば慣れてしまうけれど...。
主人公のライトニング姐さんがとてもいい。大概、FFの主人公とは反りが合わ なくて覚めてしまうのだけど、姐さんとならやっていけそうな気がする。
セーブポイントもちょくちょくあって、お気楽に進めていける感じ。


RS125の火入れのテストして積み込み。その後はガレージの掃除。ガロン缶入り
のWD-40は使いにくかった。容器に移すのが大変だし、スプレーも使いにくい。
値段としては、そう変わらないんだ。スプレー缶一本309円が293円になるくら
い。

その後はガレージの大掃除。




マクガイバー、シーズン3、後半はなにかとても萎んでしまった。もうこの先は
買わないかも。ニッキーとペアで痛快にやってくれればそれだけでもよかった
のに。

菜園状況。休耕になっている場所に苦土石灰を蒔いて、たっぷり牛糞堆肥をす きこんでおきました。採り残しから発芽したジャガイモは、この寒さでしおれ てます。この時期からじゃ無理なのか。

キャベツ。結球はまだまだ。そろそろ害虫もないから安心?

ここまでやられてしまうと、もうだめだろうね...。

トマト最後の収穫。もういくら待っても赤くならない。一見もう食べれなさそ うだけれど、このまま赤くして、問題ないところだけカジるとおいしい。

やらなくちゃと思いつつ放置していたモニタの処分。愛用の両手鎚で粉砕。ち なみに画面側から割ろうとすると結構大変。

後は不燃ゴミ。

素材として使えそうなとことして、これだけとっておいた。

ステッピングモータを動かすのもちょっとはじめました。手持ちの2SD1830が 100V,8Aで十分よさそうなので、とりあえずこれで。たぶんこんな感じでいいの だと思う。これをX,X#,Y,Y#の4つ用意して、タイマでオンオフしてやればいい。
H8/3052(5V)でテストなので、出力Highレベル許容電流が2.0mAなので2.5kΩに。 総和は40mAまで。

ポートのオンオフで12Vがオンオフされるところまで確認。



マクガイバー、シーズン2は一話の「死のコンピューター指令」(THE HUMAN
FACTOR)以外はどうもパッとしなかった。この邦題はいい。メタルの邦題を彷彿
とさせる。最近は当時の雰囲気を出すため以外にはこういうイカした訳(?)がな
いのが残念だ。ただ英語をカタカナにしただけなんて。

それはともかく、シーズン3はどれもいい。そして新しく相棒となったニッキー がいい。マクガイバーとの掛け合いが最高です。はじめてコンビを組んだ時に は東ドイツから気球で脱出する際に燃料が切れてしまい、重量を減らすために 只一人パラシュートジャケットを着用していたニッキーはマクガイバーに降り ろと言われて降ろされてしまう。呪い節をわめきながらニッキーは気球から飛 び降ります。その後現われるニッキーはもうカンカン。
次はマクガイバーが友人の死で山小屋にひきこもってしまう。そこでニッキー はその山小屋に向う。励ましてるのか喧嘩しにいってるのかわからないような 感じだが、そこで殺人鬼に狙われる。そこの過程で段々マクガイバーはいつも の調子を取り戻していくのだけど、最後は350mの絶壁の途中の岩棚。元気になっ たマクガイバーは「さぁ登っていくぞ!」と準備をする、もうロッククライミン グの恐怖はこりごりなニッキーは「ヘリの救助まで待つ」と譲らない。マクガ イバー:「夜は冷えるから気をつけろよ、明日の朝、ヘリで迎えに来る」、ニッ キー:「あたしをここに一人残して行く気?」観念したニッキー渋々、命綱を装 備する。そこで話は終わり。
その後の勝手な想像として、登りきったところでピーターのヘリがちょうどやっ てきて、マクガイバー:「やぁピーター、来てくれると思ってたよ。」ニッ キー:「マック!マクガイバー!!!!」とぶち切れる。ピーター:「はっはっはっ、 水と油だからこそ混ざり合わなくていいのかもな。」
目に浮ぶようだ...。
残念ながらニッキーの出番はシーズン3だけ。いいキャラなんだけどね...。と ても残念だ。

ガレージ資材を例によってMonotaROから調達。WD-40は今迄、普通のスプレー缶 を使っていたのだけど、ガロン缶にしてみた。こんなスプレーボトルで?という ところに興味を持った。
コーザイのセーフティークリーンは今回ちょっとリッチにセーフティクリーン Sにしてみた。ちょっと高い。この洗浄力には信頼を置いてます。25000km走っ たカーボンびっちりのXLR25Rのヘッドもこの原液に一晩つけておいたらニュルっ とカーボンがとれた。最近はチャンバーのカーボン落としにも使っている。た だチャンバーのカーボン落としにはちょっと足りないような気もする。

ハードディスクは百均で買ってきたタッパに入れました。穴開けの最後の一個、 実験にオートポンチをあててみたところ、やっぱり割れた。通気穴ということ に。百均のタッパは割れ易いから加工がちょっと面倒。



電源ジャンク箱。捨てる機械の中からなんとなく取り出しておいていた。ついに
使う機会が。



一つはこれ。昨日セットアップしたディスク用。これはSH4A用の仕込み用。な んか箱に入れておかないと。

これはステッピングモータのテスト用に12V電源。妙にいい作りがいいけれど、 これはなんだろう。WSの周辺機器かな。




フィン修正の終わったラジエターは、コーザイのセーフティクリーンを適当に
希釈した液に数時間漬け置き。フィンを開けてみたら、中でオイル汚れがたまっ
ていた。



その後、お湯をエンジンクリーナーで吹いて掃除。ちょっと汚れがとりきれな かったか。今日はこの後、お風呂に漬けておいて洗浄剤落とし。
ここまで来ると、今使っているCR85のラジエターよりずっと綺麗。あっちも整 備しておかないと。

久々にMS-DOS6.2をハードディスクにインストールした。特に意味はなく、ちょっ とFAT16領域を作っておきたかったのでついでにお遊び。
qemu -fda msdos-6.2.img -hda /dev/rwd1d -boot a
し、
format c: /s
どうもマイブートローダ、二番目以降のディスクのチェーンロードに問題があるようだ。




水温計をラジエターから外して試験。やっぱりだめだ。ちょっと針がピクリと
するだけで、動かない...。よくよく見ると今は亡き大森メータだ。

NFの間でもアナログとデジタルでセンサプラグのピッチが違うのでラジエター の互換性はない。

どっかで余ってるのを見たことがある気がする..と、ガサゴソ探してみたら一 個発見。よかった。
アルコール温度計  RS125水温計 (℃)
              75  78
              70  73
              66  70
              58  62
              55  58
              53  55
              51  53
              47  50
              43  45
OK。

ついでにフィン修正も。アナログ水温計の場合、そう簡単に水温計を外せない のでメンテナンス性が悪くてつい面倒になってしまう。洗浄ですら面倒だ。こ の機会に。残り3列。
フィン修正はやる前はとても気が乗らない作業なのだけど、やりはじめると妙 にはまるんだよね。..ここは無理せず、まず下を押さえてから上を開いて...と か、段々自分のピック捌きに惚れ惚れしてきたり^^。はっと気付くと一時間く らい経っていて目がパチパチしてしまう。
この残りの列のように完全に潰れてしまったのは、4パスくらいにわけて、最初 は隙間をちょっと入れるだけ、二回目は隙間を左右に拡げて、三回目でフィン の向きを(無理しない程度に)修正して、最後に調整するといい感じ。




測距センサもついでに実装。今回のロガーはこれで。不満なところも多々ある。
  • I2Cモジュールのエラー処理が不十分。0x08(スタート条件発行)で失敗が連 続するのを調べないと。0x30(マスタ送信でデータ転送後にスレーブからACKが 来ない場合は、どうせスタート条件送ってSLA+Wからやり直さざるを得ないので、 そこでストップ条件で、次の機会にやりなおしでいい。
  • 見易いフォントにしたい。
  • スレッドセーフなタイムアウトのフレームワークが欲しい。
  • LCDのSPIをSSPにしてDMA転送にしたい。
ちょっと疲れたのでこれはまた先。

測距センサ(測定距離10cm-80cm)、このくらいの距離がないとだめ。このくらい だと、手でフォークを押し沈みしてちょうどいい感じに値がとれる。しかし... これだけの距離をどこで稼ぐか...。

LCDは、またここに。一個1000円と安いのでCR85とは別にまた買ってきてありま す。そういえば思いだした。この水温計壊れてる疑惑があったな。調べないと。

結局いい案もなく、カウルに穴あけて強力両面テープでここに設置。NFカウル だからこれでいけるけれど、04カウルだとまた別の方法を考えないと。このTカー にも04カウルを与えておこうか。





菜園状況。このチンゲンサイは、春に自家採種した種からのもの。つまり二代
目。比較に一代目と一緒に蒔いてみたのだけど、やはり大きく育たない。これ
がF1種なのかな。



キャベツ。キャベツは1/4ほどやられてしまった。今日も疑惑のある株のまわり を掘りおこしてヨトウムシを2匹殺害。ヨトウムシを潰して中から緑色の内蔵が とびでる瞬間はなんともいえず嫌だ。

未だにトマト。もうこの季節になるといくら待っても色づかずに腐ってしまう ようだ。収穫して赤くした方がいいかな。この時期のトマトはとてつもない味 がします。トマトの肝みたいな味。

寂しいチンゲンサイの収穫。ほとんど食べる部分はありません。

ロガー続き。ロガー本体、ロガーデータの処理プログラム共に、設計し直して 書き直しました。結構大変。これで今後の新しいセンサの導入が楽になるはず。
加速度モジュールのI2C通信部分は、実際のロガーの運用に組み合わせてみると、 スピードセンサの割込みで遅延したりすると、スレーブアドレスのACKがとれな くて、もう一度スレーブアドレスの送信からやらないといけない処理を入れな いといけなかったり、時にはI2Cバスエラーになるので、リセットしたり、不具 合続出。本番でちゃんと取れる気がしない...。
XLR250Rにもロガーを取りつけれるようにして、ここでまずテストにしたいな。 P-LAP以外はこれでいけるし。



動きはじめると、まだ辛い。ぶりかえしてしまったかも。健康って素晴しい。

ちょっとNetBSD/sh3について徒然に。
sh3/param.h

#define	UPAGES		3		/* pages of u-area */
#define	USPACE		(UPAGES * NBPG)	/* total size of u-area */
#if UPAGES == 1
#error "too small u-area"
#elif UPAGES == 2
#define	P1_STACK	/* kernel stack is P1-area */
#else
#undef	P1_STACK	/* kernel stack is P3-area */
#endif
UPAGESが2の場合、カーネルスタックは1ページのみで連続領域なのでスタック ポインタをP1で持てる。しかし、UPAGESが3以上の場合、そのカーネルスタック 2ページはP3では連続していてもP1では必ずしも連続しないので、スタックポイ ンタはP3で持たないといけない。
実際のところは最初のページのstruct user(今はpcb)の後までカーネルスタック として使えるのだけど、そこはなしということになる。
なんでこれがあるかというと、SH3の場合はH/Wでワイヤードエントリを作れな いので、割込まれた時にカーネルスタックをアクセスしてさらにフォルトして しまうのを避けるために、その場で直接カーネルスタックをTLBに載せるという 方法をとった。そのトリッキーな動作のデバッグ用。実際のところ、割込みが きつくなると4KBではカーネルスタックが足りなくなる。
NetBSD/sh3の実装は最初から__SWAP_BROKEN、つまりu-areaはスワップアウトし ない。これはなんでこうしたかというと、u-areaの中のポインタをu-areaに持っ ていると、それをスワップアウト/インされた時にリマップしないといけないの が面倒だからだ。
今回u-areaのスワップが廃止された。カーネル側でそれを廃止したため、 u-areaは匿名領域からとるのではなく、uvm_km.cあたりのカーネル領域のプー ルからとることになった(スワップアウトする必要が一切なくなったので)。カー ネル領域はページアウトされない。
匿名領域の確保の場合、保護のために(ユーザにも使われるので)ページをゼロ クリアするのだけど、カーネル領域はそれは必要ないのでゼロクリアされない。 ということでゼロクリアを期待していたコードが動かなくなってしまった。 pcb_onfaultにゴミが入っていたりすると、TLBミスした時におかしい挙動になっ てしまう。
昔からu-areaはゼロにしないという設定だったのだけど、いろいろな設定の関 係でたまたまゼロになっていた。(もしかするとたまにゼロじゃない時もあった のかも)
ちょっと後半あやふや。
昔のカーネル
cpu0 at mainbus0: SH4A 599.999 MHz PCLOCK 49.999 MHz
cpu0: 32KB/32B 4-way set-associative Instruction cache.
cpu0: 32KB/32B 4-way set-associative Data cache.
cpu0: U0, P0, P3 write-back; P1 write-back
cpu0: full-associative 4 ITLB, 64 UTLB entries
cpu0: multiple virtual storage mode, SQ access: kernel, wired 7
cpu0: 32bit physical address mode. TLB-compatible mode.
VPN:80000000 (V) PPN:0 (V) 512MB, bufferd write, cacheable, write-back,
VPN:a0000000 (V) PPN:0 (V) 512MB, bufferd write, uncacheable, write-back,
shb0 at mainbus0
scif0 at shb0
scif0: console
PCB0xc1820000=>5ffde000 ←u-areaはanonからもってきている。これはゼロクリア
PCB0xc1823000=>5ffdb000
PCB0xc1826000=>5ffd8000
PCB0xc1829000=>5ffd5000
PCB0xc182c000=>5ffd2000
PCB0xc182f000=>5ffcf000
PCB0xc1832000=>5ffcc000
PCB0xc1835000=>5ffc9000
pmap_prefer 1
PCB0xc1832000=>5ffcc000
rn_init: radix functions require max_keylen be set
PCB0xc1835000=>5ffc9000
root on md0a dumps on md0b
mountroot: trying ffs...
root file system type: ffs
今のカーネル
cpu0: 32bit physical address mode. TLB-compatible mode.
VPN:80000000 (V) PPN:0 (V) 512MB, bufferd write, cacheable, write-back,
VPN:a0000000 (V) PPN:0 (V) 512MB, bufferd write, uncacheable, write-back,
shb0 at mainbus0
scif0 at shb0
scif0: console
PCB(new)0xc2262000=>febc000 ←u-areaはカーネルのプールページから持ってきている。
PCB(new)0xc2265000=>feb9000
PCB(new)0xc2268000=>feb6000
PCB(new)0xc226b000=>feb3000
PCB(new)0xc226e000=>feb0000
PCB(new)0xc2271000=>feac000
PCB(new)0xc2274000=>fea9000
PCB(new)0xc2277000=>fea6000
pmap_prefer 1
pmap_growkernel: fe93000 for 9
pmap_growkernel: fe92000 for 10
PCB(new)0xc2274000=>fea9000
rn_init: radix functions require max_keylen be set
PCB(new)0xc2277000=>fea6000
root on md0a dumps on md0b
mountroot: trying ffs...
root file system type: ffs
WARNING: no TOD clock present
WARNING: using filesystem time
WARNING: CHECK AND RESET THE DATE!
PCB(new)0xc2271000=>feac000
PCB(new)0xc226e000=>feb0000
PCB(new)0xc226b000=>feb3000
PCB(new)0xc2268000=>feb6000
__pmap_asid_alloc: 1
init: copying out flags `-s' 3
プロセスの起動について。
init: copying out flags `-s' 3
ここで新しくプロセスを作ってそれがASID1になった。
tlb_exception: ASID1
まずはスタックをアクセスしてフォルト。ここで失敗するのはこの領域の
ページテーブルページもないから。
FAILED __pmap_pte_load ASID=1 va=7fffeffd
ここでuvm_faultして、ページテーブルページを割当てて、その中の該当ページ
をマップする。pcb_onfaultにゴミが入っていると、ここまでに来ずにページテー
ブルにないというところでそのままリターンしてしまうのでAbort trapしてし
まう。
------------------------------START
uvm_fault_internal start=7fffeffd 0x8900b978
pmap_enter pa=5ffc6000 va=7fffe000 0x8909aa8a
__pmap_pte_alloc 7fffe000
------------------------------END
ここではじめて触ったスタックがロードされる。ここまでで一回の例外処理。
__pmap_pte_load ASID=1 va=7fffeffd
init: copying out path `/sbin/init' 11



久々にひどい風邪ひいた。丸二日寝こんでいた。ようやく動けるようになって
きた。たぶん運動不足だ。さっさとロガー仕上げてテストに行かなければ。



        



風邪ひいたっぽい。週末はひきこもっていたのだけれど...。ちょっと秋月の測
距モジュールqGP2Y0A21 YK0Fを試してみました。Vccは3.3VとGNDとLPC2388の
A/Dコンバータの端子に接続するだけ。

測定距離は10cm-80cmで、10cm以下になると730あたりで飽和し、5cmきると値が 不定になってくる。無限遠で値は120くらい。意外にそこそこ値がとれそうな気 もしてきた。これもダメもとで実装しておこうか。



RS125整備。この象の鼻のガスケットがなくなってしまったので、t1.0のA10で
巻いてみました。ちょうどいい具合。この90'RS125Rもそろそろ20年落ち。

あとスイングアームが開いちゃってるね...。

ロガーの配線をしました。ここで問題発生。スピードセンサから無駄に割込み が入る。調べてみたところ、磁石がセンサに近づいてセンサのスイッチが入っ て、磁石とセンサが一番近付いたところでオフになり、また離れたとこでまた スイッチが入る。センサと磁石が近すぎたのが原因だった。前のTopeak130だと、 いくら近くても問題なかったのだけど、Topeak140は感度がいいのかも。スペー サでセンサ位置を調整してOK。

ロガーに加速度センサを配線しました。これ分解するのがとても大変なので、 今のうちに、タコメータ用にコンパレータの配線と、測距モジュール用にA/Dコ ンバータの配線をとりだしておこうと思っています。
次作る時は、とにかくコネクタの数を減らすことに専心しよう。バラすのに12個の コネクタを外さないといけないんだ。




加速度モジュールの整理して、1Gの値で視点を変化するテストをプログラムを
書いてみました。OpenGLなんて十数年振りだろうか。お気楽にglutで。


チップのZ軸が重力方向だと安定するみたい。X軸、Y軸が0Gになるとふらつきが ある。静止位置は十分いいけど、初動はだめね。
楽しくてしばらく遊んでいた。


LPC2388のI2Cモジュールの枠組み、なんとかできた。

こんな感じで。i2c_cmd*でステートマシンを先にi2c_commandに作っておき、 それをi2c0_executeで割込み駆動で実行する形式。
void i2c0_init (void);
void i2c0_fini (void);
void i2c0_execute (struct i2c_command *);

// Prepare state machine.
void i2c_cmd_slave_addr (struct i2c_command *, uint8_t, uint8_t);
void i2c_cmd_write (struct i2c_command *, uint8_t, enum i2c_control_option);
void i2c_cmd_read (struct i2c_command *, uint8_t *, enum i2c_control_option);


こんな感じで使います。KXP84は最初のレジスタの書き込み、読み込みからデー
タを読み書き毎に内部レジスタをインクリメントするので一括で処理が可能。
読み込みの場合にステートマシンを作っておけば、実行時に一切の負担がない
ようにしたいというのが目的(だったのだけど、実際は実行時に結構手間がかか
ることになってしまった)

void
kxp84_reg_write_6 (struct i2c_command *cmd, uint8_t reg_addr, uint8_t *reg_data)
{
  // Prepare state machine.
  cmd->current = 0;
  cmd->n_command = 0;
  cmd->busy = FALSE;

I2Cのスレーブアドレスを設定して、マスタ送信モードに。
  i2c_cmd_slave_addr (cmd, 0x18, I2C_DIR_WRITE);
KXP84のレジスタアドレスを送信。
  i2c_cmd_write (cmd, reg_addr, I2C_CONTINUE);
  i2c_cmd_write (cmd, *reg_data++, I2C_CONTINUE);
  i2c_cmd_write (cmd, *reg_data++, I2C_CONTINUE);
  i2c_cmd_write (cmd, *reg_data++, I2C_CONTINUE);
  i2c_cmd_write (cmd, *reg_data++, I2C_CONTINUE);
  i2c_cmd_write (cmd, *reg_data++, I2C_CONTINUE);
最後はストップ条件を発行。
  i2c_cmd_write (cmd, *reg_data++, I2C_STOP);
}

void
kxp84_reg_read (struct i2c_command *cmd, uint8_t reg_addr, uint8_t *reg_data)
{
  // Prepare state machine.
  cmd->current = 0;
  cmd->n_command = 0;
  cmd->busy = FALSE;

I2Cのスレーブアドレスを設定して、マスタ送信モードに。
  i2c_cmd_slave_addr (cmd, 0x18, I2C_DIR_WRITE);
KXP84のレジスタアドレスを送信して、反復スタート条件に。
  i2c_cmd_write (cmd, reg_addr, I2C_START);
I2Cのスレーブアドレスを設定して、マスタ受信モードに。
  i2c_cmd_slave_addr (cmd, 0x18, I2C_DIR_READ);
  i2c_cmd_read (cmd, reg_data, I2C_CONTINUE);
  i2c_cmd_read (cmd, reg_data + 1, I2C_CONTINUE);
  i2c_cmd_read (cmd, reg_data + 2, I2C_CONTINUE);
  i2c_cmd_read (cmd, reg_data + 3, I2C_CONTINUE);
  i2c_cmd_read (cmd, reg_data + 4, I2C_CONTINUE);
最後はストップ条件を発行。
  i2c_cmd_read (cmd, reg_data + 5, I2C_STOP);
}

これでステートマシンができあがるので、使う時にこれをi2c_executeします。
I2Cモジュールの方は、

void
i2c0_init ()
{
  // I2C0
電源を入れて、クロックを供給します。
  mcu_peripheral_power (PCONP_PCI2C0, TRUE);
  mcu_peripheral_clock (PCLK_SPI, CCLK4);	//72/4=18MHz
  // Set pin to I2C function.
ピンは多重化されているので、I2Cモードにします。
  mcu_pin_select (0, 27, 1); //SDA0
  mcu_pin_select (0, 28, 1); //SCL0
400KHzになるように設定。
  // Setting the I2C data rate and duty cycle.
  // 18MHz / (22+23) = 400KHz
  *I2C_SCLH (0) = 22;
  *I2C_SCLL (0) = 23;
以前の状態をクリアします。ここでAA(Assert Acknowledge)もクリアしている
ので、このモジュールはマスタです。AAをクリアしなければ、他のマスタから
のスレーブアドレスや、一般呼出しに答えることができるのでスレーブになれ
る。
  // Disable I2C module with clear pending status.
  *I2C_CONCLR (0) = CONCLR_VALID_BITS;
割込みがとれるようにして
  // Interrupt Enable
  *VICIntSelect &= ~VIC_I2C0;	// IRQ
  *VICIntEnable |= VIC_I2C0;
I2Cを動かします。今回マスタ送信/受信しか使わないので、自分自身のスレーブ
アドレスは設定しません。(設定しても使われない)
  // Enable I2C interface.
  *I2C_CONSET (0) = CONSET_I2EN;
  udelay (100);
}

void
i2c0_fini ()
{

  // Disable I2C module.
  *I2C_CONCLR (0) = CONCLR_VALID_BITS;
  // Power down.
  mcu_peripheral_power (PCONP_PCI2C0, FALSE);
}

void
i2c_cmd_set_opt_func (struct i2c_state *ctx, enum i2c_control_option opt)
{

  switch (opt)
    {
    case I2C_CONTINUE:
      ctx->opt_func = __i2c_continue;
      break;
    case I2C_START:
      ctx->opt_func = __i2c_start;
      break;
    case I2C_STOP:
      ctx->opt_func = __i2c_stop;
      break;
    }
}

void
__i2c_start ()
{
  DPRINTF ("\n");
スタート条件を設定
  *I2C_CONSET (0) = CONSET_STA;
}

void
__i2c_stop ()
{
  DPRINTF ("\n");
ストップ条件を設定
  *I2C_CONSET (0) = CONSET_STO;
}

void
__i2c_continue ()
{
  DPRINTF ("\n");
  // Nothing to do.
}


void
i2c_cmd_slave_addr (struct i2c_command *cmd, uint8_t slave_addr, uint8_t dir)
{
  struct i2c_state *state = cmd->state + cmd->current++;
  cmd->n_command = cmd->current;
  assert (state);
通信するスレーブアドレスと、通信方向を設定。(dirは読み込みが1です)
  state->func = __i2c_slave_addr;
  state->data = (slave_addr << 1) | dir;
}

これは実際に割込みハンドラから呼ばれるルーチン。
bool
__i2c_slave_addr (struct i2c_command *cmd, uint32_t status)
{
  struct i2c_state *state = cmd->state + cmd->current++;
これが呼ばれていい条件はスタート条件と、反復スタート条件が発行し終った
時だけ。ここでターゲットとするスレーブと通信方向を送信します。
  if (!(status == 0x08 ||	// START condition.
	status == 0x10))	// Repeated START condition.
    return FALSE;

  DPRINTF ("slave=%x dir=%x\n", state->data >> 1, state->data & 1);
  // Set Slave address and transfer direction.
  *I2C_DAT (0) = state->data;

  return TRUE;
}

void
i2c_cmd_write (struct i2c_command *cmd, uint8_t data,
	       enum i2c_control_option opt)
{
  struct i2c_state *state = cmd->state + cmd->current++;
  cmd->n_command = cmd->current;
  assert (state);

  state->func = __i2c_write;
  state->option = opt;
  state->data = data;
  i2c_cmd_set_opt_func (state, opt);
}

bool
__i2c_write (struct i2c_command *cmd, uint32_t status)
{
  struct i2c_state *state = cmd->state + cmd->current;
これが呼ばれていいのは、スレーブと通信方向を送信して、そのスレーブから
ACKがやってきた時(0x18)と、前回の送信が終了してスレーブからACKが返って
きた時だけ。
  if (!(status == 0x18 ||	// after SLA+W's ACK.
	status == 0x28))		// previous data transfer's ACK.
    return FALSE;

  if (status == 0x18)
    {
ここでスタート条件をクリアします。(しないと延々とスタート条件を発行することに
なるので反復スタート条件終了の0x10での割込みが延々と入る)
      // Clear Start condition.
      *I2C_CONCLR (0) = CONCLR_STAC;
書き込みの場合、ここで最初のデータを送信できます。
      *I2C_DAT (0) = state->data;
送信終了後の割込みをハンドルするためにステートは次に進みません。
      // don't increment cmd->current. wait until next ACK
      DPRINTF ("data=%x\n", state->data);
    }
  else
    {
これは何らかのデータをスレーブに送信して、スレーブからACKが戻ってきた時。
      cmd->current++;
データ送信が継続送信であったなら、次のデータを送信します。
      if (state->opt_func == __i2c_continue)	// previous transmit.
	{
	  *I2C_DAT (0) = cmd->state[cmd->current].data;
	  DPRINTF ("data=%x\n", cmd->state[cmd->current].data);
	}
      else
	{
もう次のデータがないのであれば、反復スタート条件、あるいはストップ条件を
発行します。
	  state->opt_func ();	// start or stop or continue.
	}
    }

  return TRUE;
}

void
i2c_cmd_read (struct i2c_command *cmd, uint8_t *buffer,
	      enum i2c_control_option opt)
{
  struct i2c_state *state = cmd->state + cmd->current++;
  cmd->n_command = cmd->current;
  assert (state);

  state->func = __i2c_read;
  state->buffer = buffer;
  i2c_cmd_set_opt_func (state, opt);
}

読み込みの際は、データ読み込み終了後、ACKかNOT ACKをマスタからスレーブに
返すことで、転送の終了/継続を伝える必要がある。
void
__i2c_issue_ack (struct i2c_command *cmd)
{
  if (cmd->state[cmd->current].opt_func == __i2c_continue)
    *I2C_CONSET (0) = CONSET_AA;	// next ACK
  else
    *I2C_CONCLR (0) = CONCLR_AAC;	// next NOT ACK
ACKであれば、スレーブはさらにデータを送ってくるし、NOT ACKであれば
送信終了と理解して、データは送ってこない。
}

bool
__i2c_read (struct i2c_command *cmd, uint32_t status)
{
  struct i2c_state *state = cmd->state + cmd->current;

  if (!(status == 0x40 ||	// after SLA+R's ACK
	status == 0x50 ||	// will return ACK
	status == 0x58))	// will return NOT ACK
    return FALSE;
  assert (state->buffer);

  switch (status)
    {
    case 0x40:
スレーブアドレスと通信方向がスレーブに伝わった後の割込み。スタート条件を
クリアします。読み込みの場合は、まだここでデータを読むことはできない。
読めるのはこの次の0x50の割込み。
      // Clear Start condition.
      *I2C_CONCLR (0) = CONCLR_STAC;
ここで、NOT ACKなら一切のデータは読めない。ACKにするので次にデータが来る。
      __i2c_issue_ack (cmd);
      break;

    case 0x50:	// ACK (continue)
スレーブからデータが来た。
      *state->buffer = *I2C_DAT (0);
      cmd->current++;
ここで、次のステートのACKかNOT ACKかを設定する。どちらにしても次のデー
タは来る。そのデータが来た時に0x50(ACK)か0x58(NOT ACK)になるかの選択。
つまり、データが来てからACKかNOT ACKを発行するのではない。先に用意して
おく。
      __i2c_issue_ack (cmd);
      break;
    case 0x58:	// NACK (last)
この読み込みでNOT ACKが発行されることになっている。そしてその後に反復スタート
条件か、ストップ条件を発行する。
      cmd->current++;
      *state->buffer = *I2C_DAT (0);
      state->opt_func ();
    }
  DPRINTF ("data=%x\n", *state->buffer);

  return TRUE;
}

void
i2c_status ()
{
 スタート条件は明示的にクリアしないといけないけれど、ストップ条件、ACKは
自動的にクリアされる。

  uint32_t status = *I2C_STAT (0);
  uint32_t con = *I2C_CONSET (0);
  DPRINTF ("%s %x %s %s %s\n", __FUNCTION__, status,
	   con & CONSET_STA ? "STA" : "",
	   con & CONSET_STO ? "STO" : "",
	   con & CONSET_AA ? "AA" : ""
	   );
}

void
i2c0_execute (struct i2c_command *cmd)
{
指定されたステートマシンで通信をします。これはとりあえず版。できれば寝
て、タイムアウトが欲しい。

  assert (!cmd->busy);
  cpu_status_t s = intr_suspend ();
  __protocol = cmd;
  __protocol->success = FALSE;
  __protocol->current = 0;
  __protocol->busy = TRUE;
  intr_resume (s);

  DPRINTF ("kick!\n");
  i2c_status ();
  __i2c_start ();
  while (cmd->busy)
    ;
  s = intr_suspend ();
  __protocol = NULL;
  intr_resume (s);
}

void
i2c0_intr ()
{
順々に実行していきます。
  assert (__protocol->current < __protocol->n_command);

  uint32_t status = *I2C_STAT (0);
  i2c_status ();
  struct i2c_state *state = __protocol->state + __protocol->current;
  assert (state->func);
  DPRINTF ("func=%x\n", state->func);

  if (state->func (__protocol, status))
    {
      if (__protocol->current == __protocol->n_command)
	{
	  DPRINTF ("SUCCESS\n");
	  __protocol->success = TRUE;
	  __protocol->busy = FALSE;
	}
    }
  else
    {
      // Failed.
      DPRINTF ("command failed %x\n", status);
      assert (0);
      __protocol->busy = FALSE;
      __i2c_stop ();
    }

  // Clear interrupt
  *I2C_CONCLR (0) = CONCLR_SIC;
}


LPC2388のI2Cモジュールの枠組みを試作しています。割込まれた時の状態が30
近くあるんだ。マスタ送信で7個、マスタ受信で7個。送信から途中で受信にも
切り替わるので大変。でもこれを作ってしまえば、I2Cデバイスは一番お気軽な
デバイスになるはず。GND,Vcc,SLC,SLDだけ配線すればいいのだもの。あとはそ
のデバイス毎のプロトコルに合わせて処理を組み合わせるだけという状態にし
たい。


        



なんとACMからカードが届いた。前にACMで論文漁っていて、年間$99なら、ちょ
こと払って落としちゃうかと登録したのだ。英語とても苦手なので言葉で書い
てある部分はヒント程度にしかならないんだけど。



加速度センサー続き。LPC2388での実装。そういえば、NXPはフィリップスだっ た。I2Cバスはそもそもフィリップスのバス(今は特許が切れてどこでも使って いる)。それならば十分デバイスは練れているだろうということで、最初から割 込み駆動で書いてみました。とりあえずかなり強引に書いて値は取れたけれど、 これ、ワンオフならまだしも、うまくまとめるの難しいな...。そこそこベスト のワンオフを作れる、枠組みを検討しよう。
スケジューラアクティベーション続き。ブロックした時について。スケジュー ラアクティベーションというのは、タスクに対して物理プロセッサの抽象を提 供とするというのが前提になっている。それがカーネル内でブロックした時、 そのアクティベーションをそのままユーザにもって行かず、新しくアクティベー ションを用意するというのは、これは単に通知のためだ。「このプロセッサは ブロックされました」というプロセッサ状態を伝える。しかしカーネル内でブ ロックしているのでブロックが解除された時にはそこからユーザに戻るための コンテキストをカーネルで保持していないといけないというジレンマがある。
Adding Scheduler Activations to Mach 3.0

Paul Barton-Davis, Dylan McNamee, Raj Vaswani, and Edward D.Lazowska
University of Washington

Technical Report 92-08-03 Reversed March 1993
続き。
2.2.1 ブロック

アクティベーションがブロックされた時、その'event_sa'はアクティベーショ
ンそれ自身の時点として設定され、そのユーザ層への継続はsa_notify(カーネ
ルルーチン)に設定される(これらはブロックが解除される時に使われる;2.2.2
章を見よ)。プロセッサのイベントフラグはPROC_SA_BLOCKEDに設定される。こ
れによって、thread_select()は新しいスケジューラアクティベーションを通知
するために作成する(他の実行可能なアクティベーションを選ぶのではなく)。
新しく作られたアクティベーションのevent_saはブロックされたアクティベー
ションを指し示す。新しいアクティベーションはsa_notify()で初まり、それは
アップコール用の引数を置くためにユーザ層のスタックをとってくる。その引
数は現在のアクティベーションと、ブロックされたアクティベーションである。

ユーザ層のスタックは、トラップから返るようにその場で設定され、プログラ
ムカウンタはタスクのアップコールの入口であるsa_blocked()に設定される。
最終的に、通知のためのアクティベーションはthread_exception_return()を使っ
て、ユーザ層で実行を始める。


加速度モジュール続き。本番のテスト用のLPC2388に継ぎました。急いでるとい
きなりロガーに配線しだすのだけど、ちょっとのんびり。LPC2388はI2Cモジュー
ルが三つある。そのうちの一つだけがオープンドレインでI2Cを完全に満たす。

とりあえずレジスタ定義を書いたところまで。データシートを見ると、やはり ステートを調べるのが複雑だな...。

スケジューラアクティベーション続き。実際のアップコールについて。このあ たりからスケジューラアクティベーションはだめなんじゃないかというような 香りがしてくる。レースコンディションをなんとかするために無理しているよ うな...。
アップコールの一般的で、効率的な枠組がないと。それが簡単ではないのはシ グナルの歴史が物語っているのかもしれないけれど...。
Adding Scheduler Activations to Mach 3.0

Paul Barton-Davis, Dylan McNamee, Raj Vaswani, and Edward D.Lazowska
University of Washington

Technical Report 92-08-03 Reversed March 1993
続き。
2.2 カーネルイベントの扱い

スケジューラアクティベーションの枠組の中で、特定のカーネルイベントはタ
スクに通知される。通知はカーネルからユーザ層へのアップコールとして実装
され、その引数は以下に述べる通りである。カーネルからユーザ層に送られる
のは四つの通知がある。

 + blocked (new_sa, event_sa, interrupted_sas): new_saはevent_saがブロッ
   クされたことを伝える。interrupted_sasは通知を配送するために割込まれ
   たかもしれないアクティベーションを照会する(*)。2.2.1章で述べるように、
   この'blocked'の通知の場合ではこの引数は常にNULLである。(*)この場所は
   interrupt_sas(複数形)と呼ばれる。それはアクティベーションは通知の準
   備をしている間にカーネルの中でブロックされることがあるからだ。この場
   合では、幾つかのアクティベーションは最終的に配送される前に割込まれて
   いるかもしれない。

 + unblocked (new_sa, event_sa, interrupted_sas): new_saはevent_saのブ
   ロックが解除されたことを通知する。interrupt_sasは通知を提供するのに
   横取りされたかもしれないアクティベーションを照会する。

 + preempted (new_sa, event_sa, interrupted_sas): news_saはevent_saがプ
   ロセッサの再割当てよって横取りされたことを通知する。interrupted_sas
   は通知を提供するのに割込まれたかもしれないアクティベーションを照会す
   る。

 + processor_added (new_sa, event_sa, interrupted_sas): new_saは新しく
   プロセッサがタスクに割当てられたことを通知する。この通知では
   event_saとinterrupted_sasは両方ともNULLである。(2.2.4章を見よ)

これらの四つの通知の実装は以下に続く四章で述べる。まず最初に必要となる
背景について規定する。2.2章の以下の部分は相当詳細だということを確認して
おく。

スケジューラアクティベーションの状態の決定的な構成要素はそのユーザ層で
の継続で、それは、カーネルの継続([DBRD91]で述べられた)に似ているが、ユー
ザ層に戻るのではなく、カーネルルーチンを指定して戻る。これを、アクティ
ベーションの実行をアップコールからユーザ層に制御を移したい時に設定する
(2.2.1章を見よ)。

スケジューラアクティベーションはevent_saとinterrupted_sasの二つの引数も
あり、それは他のアクティベーションの場所であり、通知の間にそれらの情報
をユーザ層に伝えることを許している。この情報はアクティベーションそれ自
身、それが実行したいたプロセッサや、そのユーザ層のレジスタ状態を含んで
いる。

カーネルはthread_select ()で、次に事項するスケジューラアクティベーショ
ン、あるいはカーネルスレッドを選択する。

プロセッサ毎のフラグを、thread_select ()が通知が必要かどうかのために管
理する。このフラグの値は、PROC_SA_BLOCKEDがブロックしたイベントに、
PROC_SA_HANDLING_EVENTが通知中に、PROC_ALLOCATEDが、プロセッサセット間
でのプロセッサの再割当てである。thread_select()が、プロセッサのイベント
フラグがこれらの値であれば、通知をする手配をする。

次の章では、一般的な用語でイベントの扱いについて述べる。さらに詳細な
記述は付録 A.3にある。


MonotaRO(モノタロウ)
あわせて読みたい