日記 (2008年12月)。
$Id: 200812.php,v 1.35 2009/11/05 04:49:49 isaki Exp $

2008/12/01 (月)
咳17日目。加湿器のおかげで今朝はわりと楽に起きれた模様。
う、もしかして、netboot が X68030 でこける (11月30日の日記) のは、 こういう手抜き (2003年1月18日の日記) が原因か?
fdc(4) よりなんとかなりそうな pow(4) を見てみることにする。 とりあえず現状。5.99.3 GENERIC + LOCKDEBUG で電源ボタン押すと こうなる。
Mutex error: lockdebug_wantlock: acquiring sleep lock from interrupt context

lock address : 0x0000000001ca8f0c type     :     sleep/adaptive
initialized  : 0x00000000000b1ea6
shared holds :                  0 exclusive:                  0
shares wanted:                  0 exclusive:                  0
current cpu  :                  0 last held:                  0
current lwp  : 0x0000000001cabc80 last held: 000000000000000000
last locked  : 0x00000000000bfa08 unlocked : 0x00000000000bfab0
owner field  : 000000000000000000 wait/spin:                0/0

Turnstile chain at 0x25d0a0.
=> No active turnstile for this lock.

panic: LOCKDEBUG
Stopped in pid 0.2 (system) at  netbsd:cpu_Debugger+0x6:     unlk   a6
db>
割り込み中に sleep しちゃだめよってことで powintr() の中で psignal(9) 呼んでるのが直接の原因なのは分かった。 poffd(8) を起動してなければ psignal() のところは通らないので、 ちゃんと panic しないことも念のため確認してみる。 あとはこれをどう直すのが正しいのか、いつからどうしてこうなったのか、 というあたりかな。今日はここまで。 関係ないけど pow_softc の pid いらんよな…。

2008/12/03 (水)
咳19日目。咳のほうはだいぶん治まってきたんだが、 昨日から今度はのどが痛いな。
pow(4)。えっと、、よく分かってないんだけど、 割り込み中からユーザプロセスにシグナルを 送るにはシグナルトランポリン使うんかな。 まーなんかそもそも、このデバイスのデザインのほうが、 どうなん?という気もせんでもないけど。

2008/12/05 (金)
咳21日目。のど3日目。 つばを飲むのものやっとな状態が続いてるのでさすがに耳鼻咽喉科に行ってみた。 で、風邪がまだ治ってなくて、のどの腫れが引いてないだけだそうで。 ああそうすか。 で、もらった薬(抗生物質)飲むとわりと効いたっぽい。 正直なもんだな。
そういえば、CS(721) で再放送してた「ふしぎな島のフローネ」を見終えた。 小学1年か2年の夏休みにやってた再放送を所々見て以来なので実に 25年ぶりの念願叶って全話とおして見れた格好。 昔見たので覚えているのは、ゴムの木からゴムを取り出して 長靴を作る話 (第26話) とか、別荘に狼が襲ってきたために 屋根材を燃やして狼をよけるという話 (第27話) かな。 で、もちろん木の上の家もそうだけど、 そういう無人島という限られたリソースの中でいかに物事を解決するかと いうところが見てて楽しいわけで、 別にこの歳になって、聞き分けのないフローネやジャックが巻き起こす クオリティの低いドタバタ劇を見て楽しいわけでもないし。 子供向けの番組なのでまあネタにマジレスしてもしょうがないわけではあるけど、 物語の展開を無茶振りして突拍子もない事件を起こしておいて 最後は一件落着っていう都合のいい展開が多いからね。 急に知らない病気になったり、かと思うとあっさり治ったりとか。 まあ子供向けだからね。 にしても、ジャックとメルクルはうざかったな。 それと、出てくる動物の知能が高すぎ。 メルクルでも5歳児並み (知らんけど) の知能は持ってて 明らかに空気の読めない行動をするし (動物の場合は空気関係ない行動をとるってのが正しいんでないかと)、 犬のジョンに至っては明らかに人間でいう中学生以上の知能は持ってて 完全に空気が読めている。恐い恐い。 第50話(最終話)は一本丸々エピローグとも言える話なんだけど、 30分もあるともうひとドタバタあって、エピローグというにはちょっと長い。 ストラトスフォーのは短すぎて何のこっちゃ分からんし、 ナディアやプラネテスのはほどよかったと思う。

2008/12/06 (土)
咳22日目。寒波で初積雪。
こんな状況で、市民球場でカープ OB オールスター戦。 観衆28000人だそうで。
つか寒いよ?。 お昼12時半で気温1度。 これまでの市民球場観戦の最低気温 (2007年4月4日の日記) を更新。 さすがに3日前から土曜日はめっさ寒いという話だったので、 それなりに重装備はしてきたけど。
監督の古葉さんが代打で登場。 小雪の吹雪く中、金石 vs 古葉監督。

さすがに黄金期以前の人は全く知らない人ばっかり。 やっぱり、古葉監督、阿南監督、安仁屋さん、外木場さん から(山本)浩二、衣笠、(高橋)慶彦と いったあたりがメインになってしまう。 正田、川口がいなかったのが残念。 あとは最近どころで野村謙二郎、浅井、山内とかね。

最終回 (7回) に出てきた大野はまだまだ健在。 大野 vs 山本浩二。 しかしこの写真は大野のピッチングを撮った写真としては 非常にいいタイミングでシャッター切れてるな。 Olympus C720UZ は、押してから撮れるまでのタイムラグが 結構 (0.5秒とかそういうオーダー) あるので、これはある程度 それを見越して早めに適当にシャッターを切っておいた結果なわけだが、 これは偶然ではなくて、この瞬間を撮るためにはこのどのくらい前に シャッターを押しておかないといけないかという変な技術が必要。 本格派カメラ屋さんが見たら怒るやろうな。

山本浩二は見れば見るほど、B.B.ゴローに似ていて、いつまで見てても笑える。 現役時代は知ってはいるけど、バッティングフォームを見て懐かしいほどは 知らないので、それこそ山本浩二の打席や走り方のしぐさは B.B.ゴローで先に知ったくちなので。

その後、えぷ氏とみかげさんとでなぜかめいぷり。 ゆきさんがいらっしゃいましたようで(何。
pow(4)。soda さんから直面している実装方法について、 筒井さんからはデザインについて、それぞれ突っ込み。 soda さんからは割り込み中の psignal() について、 ハードウェア割り込み中で一旦ソフトウェア割り込みを 発生させたら? (意訳) とのこと。なるほど、確かに。 筒井さんからは pow(4) (+ x68k 固有の poffd(8)) じゃなくて landisk の pwrsw(4) みたいに sysmon(4) (+ MI の powerd(8)) 使うほうがいいんでね? (意訳) とのこと。なるほど、確かに。 目先、電源ボタンが押せないのは不便なので とりあえず soda さんの仰る方法で修正しておいてから、 筒井さんの仰る方法を検討してみようと思います。 お二方ともいつもありがとうございます。

2008/12/07 (日)
その過程で signal(9) を読んでたんだけど、これがまたはちゃめちゃ だったので、気付いた typo は直して勝手に commit しといた。 というか全体的に放置ぷれいしすぎな気もするけど send-pr だけしといた。エロい人よろ。
pow(4)。soda さんの助言通り softint(9) 使ってさくっと書いてみたところ、 softint_schedule() の中 (のたぶん SIMPLEQ_INSERT_TAIL あたり) で MMU fault した…。えーっと?? (汗。 今日はここまで。つーか1回カーネル試すのに15分くらいかかるからなあ。

2008/12/08 (月)
pow(4)。softint(9) 自体はちゃんと動いているっぽい。 って、biodone() が softint(9) 使ってて biodone() が動いてるんだから softint(9) は動いとるわな…。 で、確かに自分が softint_establish() したところの SIMPLEQ の head が { NULL, NULL } になっとるな。なぜじゃー。今日はここまで。

2008/12/09 (火)
咳25日目。咳というか風邪の予後のままって感じ。 午後すぎると熱っぽくなってくる。
小説 アリソンアリソンIIを読み終えた。 小気味いい感じで話が進んでいくので読みやすいかも。 舞台背景も好きだし、アリソンとヴィルの性格も好きだったかな。 てか、アリソンがドラクエ5のビアンカとややキャラかぶってる気が するんですが、気のせいですかね。ビアンカのキャラが好きな人は 読んでみてもいいかも。 I の頃ずっと、ベネディクトはおっさんの年齢だと思って読んでたので、 II の巻頭のベネディクトの紹介を読んで青年の年齢だったのでびっくりした。 読解力なさすぎ。
俺様あんてなで www.php.net のニュースがいつも遅れて出てくるのを 調べてみたら、http://www.php.net/news.rss は日付のみで時刻を返さない タコさんだからだった。代わりに http://www.php.net/feed.atom なら 大丈夫。 で、調べてたら Atom 1.0 とかで使われてる時刻フォーマットは RFC3339 らしい。へー。 あ、タイムゾーンの対応サボってるのは直さなきゃ…。
NetBSD 4.0/i386 で wm0 を tcpdump しながら、Linux PC (10.XX.XX.42) から NetBSD (10.XX.XX.30) に ARP 投げてみたんだけど、 この wm0 から発信される ARP パケットが 60バイトにパディング されてないように見えてるな (↓の2つ目ね)。 Linux 側で tcpdump してるとちゃんと 60バイトになって 届いているように見えるので、 NetBSD の wm0 のパディングと bpf の順番がアレゲってことかしらん。 掘り下げるのマンドクセ。 -current では治っていますか? とか。 ちゃんと調べて send-pr とかする人えらいと思うよ、ほんと。
14:07:50.735173 arp who-has 10.XX.XX.30 tell 10.XX.XX.42
       0x0000:  xxxx xxxx xxxx yyyy yyyy yyyy 0806 0001
       0x0010:  0800 0604 0001 yyyy yyyy yyyy 0aXX XX2a
       0x0020:  0000 0000 0000 0aXX XX1e 0000 0000 0000
       0x0030:  0000 0000 0000 0000 0000 0000
14:07:50.735185 arp reply 10.XX.XX.30 is-at xx:xx:xx:xx:xx:xx
       0x0000:  yyyy yyyy yyyy xxxx xxxx xxxx 0806 0001
       0x0010:  0800 0604 0002 xxxx xxxx xxxx 0aXX XX1e
       0x0020:  yyyy yyyy yyyy 0aXX XX2a
うむ、wm_start() の for ループの中で bpf 呼んでるのは最後っぽいから、 やっぱりパディングせずに出してるってことでいいのかな。 あー、ハードウェアが勝手にパディングしたりするんかな。 [続き 12/12]
うひょー、岡山裕子タンの オフィシャルブログが 復活してた━━━━(゚∀゚)━━━━!!
pow(4)。最初にコード書く時に誤って NetBSD4 の softint(9) を 読んでしまい、softint_establish() に渡すパラメータを間違えてた ことが原因だった。しょうもなー。 まあ、x68k の場合はそんなしょうもないミスのせいか カーネルが以下略なのかは若干カオス気味…。 で、さくっと動いた。 あー、電源ボタンでシャットダウンできるよー。これは楽。 soda さん、ありがとうございます。

2008/12/10 (水)
咳26日目。 そんな中、朝一の飛行機で東京出張。 家を出る朝6時半はまだ真っ暗で、途中高速走ってる時にようやく日が出てくる。 おまけに今日は霧がものすごくて、たぶん30m先も見えてないくらいじゃないかと。 さすがに前のめりになって運転したよ。 で、こんなんで飛行機離着陸するのかーと思いながら、 高速降りて空港へ向かう坂を登ってたら急に視界がすぱっと晴れて、 広島空港は雲海の上だった。あ、そういうオチ?

2008/12/12 (金)
咳28日目。再び病院へ行ってみる。 べ、べつに先生がめっさ美人だから行ってるんじゃないんだからねっ。(;´Д`)
[元ネタ 12/9] 筒井さんより。イマドキの NIC はみんなハードウェアでパディング するよ、とのこと。ああ、やっぱりそうなんすか。 ありがとうございます。 レイヤが上のほうのただのアプリ屋さんからすると tcpdump って わりと絶対的なものっていうイメージがあるんだけど (「tcpdump で確認したので間違いないです」みたいな)、 ドライバ屋さんからすると bpf に渡したものとワイヤ上のものが 同じかどうかは自分やハードウェアのさじ加減っていうところが あって、そこのギャップは大きいなと思う次第。

2008/12/13 (土)
NetBSD/x68k。pow(4) が電源ボタン押したら panic するやつの修正を commit しておいた。soda さんありがとうございます。 さて、続きまして筒井さんからいろいろ突っ込まれてるところに着手… したいんだが、えーっと、こりゃどっから手をつけたらええんかいな(汗。
7年目の車検完了。弟の知り合いさんのところでやってもらって 10万ちょい。 相変わらず車検は高いぉ。 つーか30年前じゃあるまいし、今どきの車、 2年ごとに車検なんかする必要ないだろうに。

2008/12/14 (日)
昨日あたりから咳もだいぶん治まった。もうちょいだ。
天気もいいので、スタッドレスに履き変える。 車検のついでにやってもらえばよかったよ…。
NetBSD/x68k。pow.c を本格的にいじろうとしてちょいと mfp っていう ローカル変数を作ろうとしたら、mfp っていう名前のマクロがあって びびった。"x68k/x68k/iodevice.h" を include してる人だけとはいえ、 その名前はちょっとインパクト大きすぎじゃないか…。 で見てたら mfp_set_*()、mfp_get_*() みたいなアクセス関数っぽい マクロが用意されているのでそっちを使うように変更。 まあ、これもそもそもなんだかなーっていう気もせんでもないけど、 mfp っていうグローバルなマクロよりはましかな。
NetBSD。 他の port のことはあまりよく知らないけど、 arch/x68k の下でもハードウェアに近いところになると たいていあっちこっちのデバイスを横断的に触る必要がある。 で、じゃーもういっそのこと、みたいなことでかどうかは知らないが arch/x68k/x68k/iodevice.h の struct IODEVICE みたいな 超便利構造体が出来たりする。 最初見た時はたまげたけどね。 構造体だからメンバ変数に名前はついてるし、 バンク切り替えなデバイスのレジスタも共用体にすればそれぞれ名前がつけられるし、 大きさ (8ビットか16ビットか) はコンパイラにも伝わるし。
x68k/x68k/iodevice.h
struct sysport {
   char pad0; unsigned char contrast;
   :
   char pad6; unsigned char sramwp;
   char pad7; unsigned char powoff;
   char pad[0x1ff0];
};

struct IODEVICE
{
   :
   struct centro io_printer;   /* 0x00e8c000 */
   struct sysport io_sysport;  /* 0x00e8e000 */
   struct opm io_opm;          /* 0x00e90000 */
   :
};
extern volatile struct IODEVICE *IODEVbase;

#define sysport (IODEVbase->io_sysport)
#include <x68k/x68k/iodevice.h>

   volatile char *sram = IODEVbase->io_sram;

   sysport.sramwp = 0x31;  /* SRAM 書き込み許可 */
   sram[offset] = value;   /* SRAM に書き込み */
   sysport.sramwp = 0;     /* SRAM 書き込み禁止 */

で、まあ便利は便利なんだけど、さすがにこれがいいとは誰も思っていなくて、 直さないといけないとは (10年前から薄々) 思っている。 ので、先人が用意したその片鱗がたぶん mfp_get_gpip() (MFP の GPIP レジスタの値を読む) とか intio_set_sysport_sramwp() (システムポートの SRAMWP レジスタに値を セットする) のようなアクセスマクロなんだと思う。 マクロの中身はメモリへの直接アクセスなのでなんてことはないが、 構造体直接アクセスよりは幾分ましか。

x68k/dev/intiovar.h
#define INTIO_SYSPORT       (0x00e8e000)
#define intio_sysport       INTIO_ADDR(INTIO_SYSPORT)
#define sysport_contrast    1
:
#define sysport_sramwp      13
#define sysport_powoff      15

#define intio_set_sysport_contrast(a) intio_sysport[sysport_contrast] = (a)
#define intio_get_sysport_contrast()  (intio_sysport[sysport_contrast])
:
#define intio_set_sysport_sramwp(a) intio_sysport[sysport_sramwp] = (a)
#include <x68k/dev/intiovar.h>

   volatile uint8_t *sram = IODEVbase->io_sram;

   intio_set_sysport_sramwp(0x31); /* SRAM 書き込み許可 */
   sram[offset] = value;           /* SRAM に書き込み */
   intio_set_sysport_sramwp(0);    /* SRAM 書き込み禁止 */
しかしこれ、MFP とシステムポートにアクセスするために ほとんどのレジスタについて set と get マクロが用意されていて、 よく書いたなーとは思うけど、 いくらなんでも 全部のレジスタに対して set と get を用意するっていうのは ちょっと不毛すぎる気もする。 今日も MFP の AER レジスタへアクセスするためにマクロを2つ追加したしさ…。

現在はこの2つの方法が混在していてどっちも極端すぎる感じはするので、 このくらい(↓)が割とリーズナブルだと思うんだけどな。 bus_space(9) と親和性のあるフォーマットにしておけば、はたから見ても まあまあ理解できるだろうし。 [続き (12/21)]

#define SRAM_foo         (0xed00XX)
#define SYSPORT_CONTRAST (0xe8e001)
#define SYSPORT_SRAMWP   (0xe8e00d)

   intio_write_1(SYSPORT_SRAMWP, 0x31);   /* SRAM 書き込み許可 */
   intio_write_1(SRAM_foo, value);        /* SRAM に書き込み */
   intio_write_1(SYSPORT_SRAMWP, 0);      /* SRAM 書き込み禁止 */
そういえば、こないだ signal(9) の typo 直したら、 外人さんから pull up よろ(意訳) っていうメールが来て、 どきどきしながら pull up してみたら、 NetBSD 5.0 に入ったようです。

2008/12/15 (月)
NetBSD/x68k。intio_write_1() みたいなものが用意できたらいいなと 思ってソースを眺めてたら 0xc00000 (I/O 空間の開始番地) を示す定数やら 変数が乱立していたので、珍しく他の port を見てお勉強中。 arch/x68k を見慣れている自分にとって arch/news68k はびっくりするほどシンプル…。 news68k は intiobase_phys が物理アドレスでの I/O 空間の開始位置。 news68k ではモデルによってこのアドレスが違うらしく、 変数になっていて locore.s の start のすぐのところで機種を見て 切り替えてるんかな。 x68k はたぶん単一モデルだからそうする必要がなかったためか、 きれいにする必然性がないから、そのうちぐだぐだになってきたと いうことかな。

ああ、またしょうもないことが気になる子ちゃん。 intiobase がいろいろ違うよ…。

port変数宣言
hp300u_int8_t *locore.s
luna68kchar *locore.s
mvme68kchar *locore.s
news68kchar *locore.s
next68kvaddr_tlocore.s
x68ku_int8_t *pmap_bootstrap.c
x68k は locore.s で intiobase をつつかないから あえて locore.s に実体を確保する必要はないけど、 locore.s で intiobase をつつく人は実体を locore.s に置くわな。 で、他の port の locore.s 見た感じだと、x68k でも intiobase は locore.s に置くほうがよさそうだな。 うーん。 おまけにみんな intiobase の初期値は 0 なのに、 x68k は pmap_bootstrap.c 内で初期値代入してあるし。

2008/12/16 (火)
つづき。 pmap_bootstrap() が intiobase と IODEVbase に値を代入するんだけど、 そこより前にコールされる intr_reset() で IODEVbase を使ってるから IODEVbase には (と intiobase にも?) 初期値が入ってるのかな。 で、intr_reset() は各デバイスの割り込みを禁止してるっぽいんだけど、 なんじゃろう、これ。 割り込みって locore.s の start の1行目で IPL7 でマスクしてるよね? デバイスの割り込みを初期化するのは xxx_attach() の仕事じゃないの? X68000 のデバイスって起動直後割り込み上がるかどうか不定なの? んなわけはないと思うが。 で、久しぶりに 筒井さんの news68k 移植話「NetBSD/news68k への道」を読んでみた。 昔読んでもなんのこっちゃだったが、今読んでもなんのこっちゃだけど、 前よりは少しは意味が分かるようになったようだ。 10年前の筒井さんレベルに追い付くのにはあと20年くらい必要そう。 それはそうと cvs log 見ると x68k_init.c は x68k port 誕生時から存在しとるな。謎だ。 まあそれ言うと x68k/dev の下には xxx_attach() の中で spl*() とか 平気で書いてあったりして、 そこってまだ割り込み、フルフルに禁止中じゃないっけ? よく知らんのだけど。 spl*() とかやると割り込みレベル下がらないっけ? とかとか。 あ、spl*() は splraise*() だから IPL7 から下がりはしないのか。 へー、なるほど。でも spl*() をここに書くのは間違いだよなあ。 なんか芋づる式。
当り前だけど x68k/x68k_init.c の intr_reset() を呼ばないように してもちゃんと起動してきて動いてるように見える。 まあ無事じゃなかったとしてもここでこれ呼ぶのは間違いだと思うので、 IODEVbase が片付いたら削除することにしよう。
intr_reset() がいらないので IODEVbase に初期値を入れておく必要はなくなった。 intiobase も pmap_bootstrap() で値を上書きするまでには 参照されてないので初期値代入しておく必要なし。 定数 PHYS_IODEV (= 0xc00000) は、 そもそも初期化する必要のないこの2つの変数の初期値としてしか 使われていないので、不要ということでよさそう。 あとは include/cpu.h の INTIOBASE と dev/intiovar.h の PHYS_INTIODEV の2つなので たぶん前者が正統で後者について考察すればいいんだと思う。今日はここまで。

2008/12/17 (水)
そういえば、朝、会社に向かって歩いてたら 高専時代の同級生から何年かぶりに電話がかかってきて、 それと同時に警察車両に呼び止められた…ではなくて、 パトロール中に偶然見掛けたらしい。ちょいと立ち話。
前からやってみたかった NetBSD の puffs で遊んでみる。 ドキュメントはほとんどないか、あってもメンテされてるかが疑問なので、 あえて特に読む努力はせずに進めることにする。 まず手始めにサンプルの pnullfs をコンパイルしてみる。 これは nullfs を puffs で実装しただけの雛型。 で、コンパイルはあっさり通って実行するとエラーが出る。 あー、GENERIC には puffs が組み込まれてないのね。 エラーが分かりにくいよ。 カーネルに以下の2行を追加。 知らないと putter を忘れてもう一回ハマる特典が必ずつく。
file-system     PUFFS
pseudo-device   putter
さくっと動いた。 ~/b は ~/a と同じものが read-only で見える例。簡単。 ちゃんと mount (や df) でも見えてる。 プロセスを落とすか umount で umount できる。 おーこれは面白い。
# mkdir a b
# touch a/file_a
# pnullfs -o ro ~/a ~/b
# ps ax | grep pnullfs
1654 ?     Is   0:00.00 ./pnullfs -o ro /home/isaki/a /home/isaki/b
# mount
/dev/wd0a on / type ffs (local)
kernfs on /kern type kernfs (local)
ptyfs on /dev/pts type ptyfs (local)
/home/isaki/a on /home/isaki/b type puffs|pnullfs (read-only)

で、さっそく pnullfs を改造して下のレイヤのファイル名中の "a" を "b" に変えて見せるのをやってみる。もちろん意味はない。 別のサンプル rot13fs を見ながら真似して実装したんだけど どうにもうまくいかない。いろいろ見てたら、 readdir は下のレイヤのファイル名を上のレイヤのファイル名に変換するけど、 それ以外の open みたいな人は上のレイヤのファイル名を下のレイヤのファイル名に 変換するからこれはエンコード/デコードの関係になるんだけど、 rot13 は rot13 だからその2つを同じルーチンで処理してあった。 そりゃそのまま真似しても動かんわ。 つーか、普通はその2つのオペレーションはきっちり区別する必要があって rot13 だけがそれを区別しなくていい特殊なケースなんだから、 このサンプルはサンプルとしては失格じゃないか?。 隣の菅原さんに、まあ rot13 = カエサル暗号だから、 これが分からないと puffs は使っちゃいけないという「暗号」なんだよ、 ということでしょうもなく納得。 ド素人様お断りのトラップか… orz。 しかし、puffs ってデバッグが簡単すぎて面白い。 イイヨイイヨー。

# find a b -type f
a/file_a
# ./pnullfs -o ro ~/a ~/b
# find a b -type f
a/file_a
b/file_b
VMware Player。nozaki さんところの xvmware を NetBSD ゲストに入れておくと、 ホストから NetBSD ゲストへのコピペも使えるようになって幸せ。
会社の忘年会だけど、なんやかんやあって、 高級焼肉ウマウマー(何。

2008/12/18 (木)
今日は謎作戦決行のための予備休み(何。
NetBSD/x68k。intr_reset() あたりの変更を 理解できてるうちに commit してしまう(コラ。 PHYS_IODEV はもう一箇所 stand/boot_ufs で使われてるので どうしたもんかなあ。 一旦マジックナンバーに置き換えて PHYS_IODEV を抹殺しておいて、 後からその辺まとめて修正したい気分。
NetBSD/x68k。なんか PHYS_INTIODEV もくそもないような気がしてきた。 I/O の範囲にアクセスするのに IIOV() を定義してそれを使ってる port と、 定義自体がない port があるらしい。 定義がない人がどうやってるかはどっから探せばいいか分からないので まだ見てない。 x68k は IIOV() は定義してないけど、 全く同じことをする別の INTIO_ADDR() を定義して使っている。 こういうのはたぶんイクナイ。 てことで、単純に PHYS_INTIODEV と PHYS_IODEV を INTIOBASE に、 INTIO_ADDR() を IIOV() に書き換えてまわればいいんじゃないかという 気もしてきた。
てことで、ここ最近気になる子ちゃんだったところを がんがん commit しちゃった。知ーらない(ぉ。
NetBSD/x68k。システムポートと I/O コントローラへの アクセスは intio(4) に寄生するような感じの実装になってて、 これを intio(4) から分離したいんだけどだめかしらん。 extent(9) が何するものか分からん…。 あー、割り込みの設定あたりが分離できない構造だからくっついてるのか?。 そろそろ pow(4) に戻ったほうがいいのかも。

2008/12/19 (金)
久しぶりに NetBSD/x68k マシンにログインしてみたんだけど、 ネットワーク越しだと何秒かに何秒かずつ固まるなあ。 キーを押して反応がすぐにある時と5秒くらい待たされる時がある。 systat :vmstat :1 も時々数秒表示がとまって、また急に 元通り動き出す。 コンソールだと問題ないように見える。 うーん、どこで何が起きてるんだろう。いつからだろう…。 2007/11/03 の 4.99.34 カーネルでもほとんど同じ症状だな。 そんなもんだったっけか。 にしても 4.99.34 カーネルだとログインプロンプトまでの時間が めっちゃ速いような気がするな。LOCKDEBUG が効いてるのか。
簿記。 「新株式申込証拠金」とか「繰越利益剰余金」とか 堅苦しくて長い名前ばっかのところに 急に「のれん」とか出てきて腰がくだけた。 「かのんちゃん」とか「れもんちゃん」の仲間かとオモタよ。
アリソンIII (上)(下)。 当然アリソンI、II と読んでから III を読むのと、 この後の続編が「リリアとトレイズ」という題名なこと、更にアニメ化された タイトルが「アリソンとリリア」だということは知っているので、 リリアって誰だよとうすうす思いながら このアリソンIII を読み始めるわけだが、 とりあえず上巻の最初、序章よりも前の最初の1ページ目の 4行目まで読んだだけで驚愕する。 さらに 4ページ目くらいまでに脳天をかち割られる。そんな展開。 結果を知らずに読まされるよりも、結果を知らされておいて 読まされるほうが余計に心臓に悪い。 ストーリー自体は I や II よりももっときなくさいので そういう意味では本当はあんまり好きじゃなくて、 I の最初のおじいさんの家に役人が来るあたりから 監獄のくだりが懐かしい。 今度もう一周読んでみよう。 あと、ずっと地理関係の描写がいまいちイメージしにくいなと思ってたら、 I のころからずっと頭の中に描いていたロクシェとスー・ベー・イルの東西の 位置関係が逆だった…。通りで東西南北の描写が理解しにくいと 思ったよ…。頭悪すぎ。早くアニメを見たい (← 脳が退化)。

2008/12/20 (土)
pow(4) をハードウェアデバイス化して commit しておく。
続きまして pow(4) の sysmon(4) 対応。 ええっとデバイスファイルを追加しないといけないのか。 随分久しぶりだったのでちょいと探したけど sys/arch/x68k/conf/major.x68k に sysmon を追加して MAKEDEV とカーネルを作りなおせばいいらしい。 で、現地で ./MAKEDEV sysmon を実行してデバイスファイルを作成。
さて、sysmon_task_queue_sched() を呼んだあとが動いてくれないな。 ああ、5.0 くらいからは ps ax でカーネルスレッドは見えなくなったんだな。 ps asx で見えるらしい。 やっぱり sysmon 用のカーネルスレッドがいないっぽい。 うん? sysmon_envsys_register() を呼ばないと sysmon_task_queue の 初期化が行われないのか。 シラネーヨ。 つーか、どういう入れ子構造になっとるんだ。manpage はー?。 いや、どう見ても sysmon_envsys_register() は場違いだな。 えっと、 sysmon_task_queue_init() は何回呼んでも最初の一回しか 実行されないようになっているので、使いたい人が勝手に呼べばよくて、 sysmon_envsys_register() もその一人っていうことかな。 manpage はー?。
当たりだったみたい。 ワカンネーヨ。 てことで sysmon(4) 対応自体は出来たっぽい。 powerd(8) を起動しといて電源ボタンを押すと i386 とかと同じように /etc/powerd/scripts/power_button が呼ばれる。 MI マンセー。 しかし、これ commit しようと思うと poffd まわりを削除したり デバイスを追加したりマニュアルとかとか大変だな。 あー、イベントって電源スイッチか EXPON 信号かとかを 拾えるようにしたほうがいいのか…。 ちょ、それは一旦 commit した後ってことで…。
ええっと、なんか思った以上に変更点が多くてびっくりしたけど、 とりあえず commit しちゃった。知ーらない(ぉ。
ちょっと LOCKDEBUG 外した時の panic でも見てみるかと思って LOCKDEBUG 外してみたら、起動した。あれ…?。いつの間に治ったんかしら。 MI 側の問題だったてことかしら。 で、LOCKDEBUG ありだと /etc/rc の最初と最後の date の間は 5分15秒、LOCKDEBUG なしだと 1分48秒。…結構効いてる。 どおりで最近なんか遅いと思ったよ。
てことで、1年ぶりぐらいに素の GENERIC が起動できたので記念パピコ。 一昨日の -current + pow0 のハードウェアデバイス化までしたところの ソースから作った GENERIC カーネルでの dmesg。
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 5.99.5 (GENERIC) #0: Sat Dec 20 17:29:59 JST 2008
	isaki@XXXXXXXXXXXX:/var/obj/x68k/obj/sys/arch/x68k/compile/GENERIC
X68030 (m68030 CPU/MMU, m68882 FPU, 30MHz clock)
total memory = 12288 KB
avail memory = 8496 KB
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root)
intio0 at mainbus0 mapped at 0x2cc000
ne0 at intio0 addr 0xece300 intr 0xf9: Nereid Ethernet
ne0: NE2000 (RTL8019) Ethernet
ne0: Ethernet address 00:50:c2:xx:xx:xx
ne0: 10base2, 10baseT, 10baseT-FDX, auto, default [0x00 0x10] auto
mfp0 at intio0 addr 0xe88000 intr 0x40
kbd0 at mfp0
clock0 at mfp0: MFP timer C
pow0 at mfp0
pow0: started by front power switch.
rtc0 at intio0 addr 0xe8a000: RP5C15
dmac0 at intio0 addr 0xe84000: HD63450 DMAC
dmac0: 4 channels available.
zsc0 at intio0 addr 0xe98000 intr 0x70
zstty0 at zsc0 channel 0
ms0 at zsc0 channel 1
neptune0 at intio0 addr 0xece000 intr 0xf9: no device found.
neptune1 at intio0 addr 0xece400 intr 0xf9: no device found.
opm0 at intio0 addr 0xe90000
vs0 at intio0 addr 0xe92000 using DMA ch3 intr 0x6a and 0x6b
dmac0: allocating ch 3 for vs.
vs0: MSM6258V ADPCM voice synthesizer
audio0 at vs0: half duplex
fdc0 at intio0 addr 0xe94000 intr 0x60 using DMA ch0 intr 0x64 and 0x65
dmac0: allocating ch 0 for fdc.
fdc0: uPD72065 FDC
fd0 at fdc0 drive 0: 1.2MB/[1024bytes/sector], 77 cyl, 2 head, 8 sec
fd1 at fdc0 drive 1: 1.2MB/[1024bytes/sector], 77 cyl, 2 head, 8 sec
par0 at intio0 addr 0xe8c000 intr 0x63: parallel port (write only, interrupt)
scsirom0 at intio0 addr 0xfc0000: On-board at 0xe96020
spc0 at scsirom0
scsibus0 at spc0: 8 targets, 8 luns per target
bmd0 at intio0 addr 0xece3f0: Nereid Bank Memory Disk
bmd0: 16 MB, 0xee0000(64KB) x 256 pages
grfbus0 at mainbus0
grf0 at grfbus0: 768 x 512 16 colors builtin display
ite0 at grf0: rows 32 cols 96
grf1 at grfbus0: 768 x 512 16 colors graphic display
ite at grf1 not configured
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "mfp" frequency 20000 Hz quality 100
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <TOSHIBA, MK2428FB, C10B> disk fixed
sd0: 500 MB, 4002 cyl, 8 head, 32 sec, 512 bytes/sect x 1024512 sectors
sd0: async, 8-bit transfers
sram0: 16k bytes accessible
bell0: YM2151 OPM bell emulation.
Kernelized RAIDframe activated
boot device: sd0
root on sd0a dumps on sd0b
root file system type: ffs

2008/12/21 (日)
NetBSD/x68k。前々から気になっていた locore.s のいくつかを まとめて commit しておく。 それと、 積年の問題だった sram(4) のハードウェアデバイス化をやっと commit。 積年といっても別に障壁があったわけではなくて、 ついこないだ intio_sysport_* を見付けたのでコードが多少きれいに なったから commit する気になったという感じ。 もう一つ、毎回忘れた頃にコードを読み直すので、 x68k って何で mainbus がないんだろう → あ、autoconf.c の中に mb っていう接頭語のデバイスが混ざってて、これが mainbus の略なのか… というループを回るので、mainbus.c を作って mainbus っていう接頭語に してみた。
[元ネタ (12/14)] intio_write_1() みたいなのを用意しようと思ったけど、これだと アドレスを指定する際のオフセットとかそういう辺で破綻することが 分かったのでボツ。というか、まあ、それを一手に解決しているのが bus_space(9) なわけで…。スマンカッタ、ちょっと吊ってくる。 結局 opm(4) がやってるように、 みんなで自分の device_private() をグローバルに置いておくしかないのかなあ。 本当はそれをやりたくなかったんだけど、なんかこれが一番きれいな気がしてきた。 [続き (2009/01/02)]

2008/12/22 (月)
空気嫁みたいな日程で、東京日帰り出張。 寝不足になったのでまた咳が出始めたよ…。
今週の探しもの (パクリ)。

2008/12/23 (火)
NetBSD。筒井さんが hp300 で ssir 付近を削除された模様。 x68k も追従したほうがよさそうなので、またその辺をお勉強しなきゃ…。

2008/12/24 (水)
うお、飯島愛死亡。orz

2008/12/27 (土)
5日連続外食。ぐたーり。
最近 NetBSD ばっかりしてたから、気付くと年末年始を控えて HDD レコーダの空きが16時間とかになってきてて、 これではとても足りないのでがんばって消化中。 空き時間40時間台までもってきたので年末年始だけは越せるか。
NHK BS2 で、 11月にあった Perfume の武道館ライブ。 うちが行ったのは1日目で、これはたぶん2日目だと思う。 ああやって俯瞰の角度で見ると改めて武道館は広いなーと思うのと、 いかに自分たちが特等席にいたのかが改めてよく分かる。 まあセンターサークルの3人の表情がしっかり分かるくらいだったからね。 バズーカの銀テープが降ってきたので当然のように拾って帰ったんだけども、 それが降った範囲も意外と狭かったのも初めて知った。 番組構成のほうは Take me Take me が入ってるのはポイント高いけども それ以外はさすがに無難な曲だけにまとめてある感じ。

2008/12/28 (日)
おうちメモ。 電源オフでも BS アンテナへ電力供給できるのはうちの部屋の液晶テレビ (AQUOS) のみなので、他の機器はつい電力供給しなくても BS が映るような 気になるが、AQUOS から BS アンテナを外したり、何らかの理由で AQUOS の主電源が切れると、他の機器は途端に自力で電力を供給しないと いけなくなる。 AQUOS から XS46 へ BS 線を繋ぎ変えた時に 運よく1階の XS40 がオフになっててこっち (XS46) に映像が 来なかったから自分で電力供給しないといけないことに気付いたけど、 たまたま XS40 がオンの時に確認したつもりになってるといざ録画を 始めても映らないってことになるところだったよ。恐い恐い。 AQUOS は電源オンオフにかかわらず常に電力供給。 一方 XS46、XS40 は「起動時だけ供給する」「常に供給しない」の選択しか 出来ない。うーん、どっちも中途半端。 分配器は全端子通電型なので 各機器が自分で責任持って電力を重畳して供給すること。 …でいいのかな。
うほっ、 NetBSD/nios2 ってなんじゃー。
NetBSD。x68k の場合、あるデバイスの動作(初期化) には 別のデバイスをアクセスする必要が多々あるんだけども、 今の実装はだれそれ構わず I/O 空間にべったりアクセスしちゃってるので デバイスの初期化順は問題にはならない。 まあそれはどうかということで、 せめてその担当デバイスさんを経由してアクセスするとか アクセスを依頼するとかそういう方法をとるべきじゃないかと。 そうすると、デバイスのアタッチ順序が問題になる。 intio(4) は (実際にはバスではないけどここでは) ISA と同じ indirect configuration なバス (2006/12/26 の日記参照) だと思うんだけど、そうか、自分の子をどの順で アタッチするかは決められないんだったな…。 そうすると intio(4) に子デバイスのアタッチ順をハードコードして おくのかなあ。 それもなんだかなあっていう気もせんでもないけど、 まあ ISA みたいな汎用バスと事情が違って、 こちとらどうせ全部内蔵デバイスなのだから、それはそれで正解なのか。

てことで、 各デバイスの NetBSD 的親子関係と x68k 的依存関係を調べた図。 色のついた矢印は、 spc は sram を触っていて、sram は system port を触っている、みたいな。 幸い循環してるところがなくてよかったとオモタ。 システムポートと I/O コントローラは今は intio(4) の一部として実装されて いるが気分的には独立したデバイスに見せたい。 点線の四角は拡張ボードなど内蔵でないデバイス。 hdc(4) (SASI コントローラ) はまだ動かないままだけど関係が深いので載せておく。 xcom(4) が mainbus(4) から直接生えているのは歴史的経緯による 実装ミスだと思うけども、実物 (PSX16550?) を知らないからないからなんとも…。

別件をググってたら NetBSD/news68k への道 (1999/05/16) にて、 mvme68k の pcc(4) は自分の子のアタッチ順を自分で持っているらしい。 ああ、やっぱそうすべきだよな。

2008/12/31 (水)
人志松本のすべらない話ザ・ゴールデン。 一番面白かったのは、最後のあ〜ちゃんと宮川大輔の掛け合い。
Perfume Portfolioに掲載されているインタビューを今更やっと読んでみた。 ライターさんの漢字の打ち間違いが多いのが非常に残念な感じだが、 まあそれはともかく、Perfume (と会社なんかにいるダメなおっさん) を見てると プロ意識というのは培ってなんとかなるものではなく、 持って生まれた天性の能力だということに気付かされた。
NetBSD。consinit() が絡むデバイスが device_t/softc 分離できない件。 カーネルの main() の中で configure() (デバイスの初期化) より 早い段階で consinit() てのがあって、これは各 MD でコンソールの初期化を 行う。x68k はこの consinit() の時点で mfp と grf および ite の 初期化をしておかないといけないらしく、 通常 configure() で行うよりも前にこれらのデバイスの attach ルーチンを起動する。 match、attach を単発で呼び出すことは出来ないので mainbus0 からなるツリーをエミュレーションして呼び出す。 それが x68k/autoconf.c の config_console() で、 config_found() の亜種のような x68k_config_found() を呼ぶあたり。 この x68k_config_found() が struct device を自前でエミュレーション してるのが元凶。 config_console() は何するかというと x68k_config_found() を使って mainbus0 から intio0 → mfp0 と辿って MFP の初期化。 もう一つは mainbus0 → grfbus0 → grf0 と辿って grf0 と その子供の ite0 の初期化。 その昔は grf0 と ite0 の初期化だけでよかったため grf(4) だけが grfbus(4) という変なバスを介して mainbus(4) に接続されて いるんじゃないかと想像。x68k_config_found() でそのほうが楽だから。 でもある時から mfp0 も初期化しないといけなくなったっぽくて、 そうなると mfp0 をアタッチするためには intio0 の初期化も しないといけないので、 今となっては grf(4) が grfbus(4) at mainbus(4) から生えてる理由はないんかしらねえ。 それとこれ mainbus0 から辿らずにいきなり必要なデバイスの 初期化ルーチンを呼び出しちゃだめなんかしら。 というのも例えば、 intio(4) は consinit() とは関係ないのに mfp(4) の attach を 呼び出すためだけに mainbus(4) から呼ばれてダミーの aux を用意して mfp_attach を呼び出すハックが入ってたりする。 どうせ汚いんなら汚染範囲が少ないほうがマシなような…。
あら、x68k_config_found() 全廃出来た…。 意外とあっさり。そしてかなりきれいになった希ガス。 英作文が出来たら port-x68k かどっかにメールでもしてみよう。 これで amiga、atari、x68k ていうお馴染みの歴史的経緯多すぎグループから 一つ脱却できるかな。数年前に subr_autoconf が結構大きく変わった時に x68k (たぶん amiga、atari も) の consinit() が動かなくなってしまい、 configure() より前にデバイスツリーを触る必要がある arch のために configure() と config_init() を分離してもらった経緯がある。 config_init() を自前で呼ばないといけない arch はこの3つだけなんよね。 てことであと2つになるかも。amiga と atari の中の人、がんばってね(ぉ。
NetBSD/x68k。mfp(4) は自分の子デバイスとして clock、kbd、pow を アタッチするように直書きしてあるけど、 pow ってついこないだまで pseudo-device だったんだけど…。 つーかこないだ pow(4) を pseudo-device から pow @ mfp にした時に mfp.c を編集せずに pow(4) が アタッチできてたこと自体がバグだったわけだな…。 うーん、アレゲな構造だな。ということでさくっと直しておく。 あと mainbus もやばいな。"*" ってワイルドカードのつもりかしら。

井崎のホームページへ戻る
isaki@NetBSD.org