[FreeBSD/fsync(1)] FreeBSD 4.3 の fsync(1) にこう書いてあった。

歴史
     fsync コマンドは、最初に FreeBSD 5.0 で登場しました。

[cvsup] リポジトリを cvsup.jp.netbsd.org あたりから cvsup してみた。そのリポジトリから取り出したソースツリーだと USE_NEW_TOOLCHAIN がどうたらと言われてまったく build.sh が 成功しないのでおかしいなと思ったら、リポジトリに build.sh,v が 含まれてなかった (うちのリポジトリ用のディレクトリは使いまわし だったのでかなり古い頃の build.sh,v が残っていた)。 壊れてんのかしら。 [続き]

[x68k/sysinst] sysinst がいつからこけるのか調べようと思って 原始的に昔のソースで build しようと思っても毎回ここでこける。 何間違えてんのかしら。

cc -c -DLOCALEDIR=\"/var/obj/alt/src/../tools/share/locale\" -DGNULOCALEDIR=\"/v
ar/obj/alt/src/../tools/share/locale\"  -DLOCALE_ALIAS_PATH=\"/var/obj/alt/src/.
./tools/share/locale:.\" -DHAVE_CONFIG_H -I.. -I. -I/var/obj/alt/src/tools/texin
fo/../../gnu/dist/texinfo/intl -I/var/obj/alt/src/tools/texinfo/../../gnu/dist/t
exinfo/lib  -O  /var/obj/alt/src/tools/texinfo/../../gnu/dist/texinfo/intl/local
ealias.c
/var/obj/alt/src/tools/texinfo/../../gnu/dist/texinfo/intl/localealias.c: In fun
ction `read_alias_file':
/var/obj/alt/src/tools/texinfo/../../gnu/dist/texinfo/intl/localealias.c:337: vo
id value not ignored as it ought to be
/var/obj/alt/src/tools/texinfo/../../gnu/dist/texinfo/intl/localealias.c:341: vo
id value not ignored as it ought to be
*** Error code 1

Stop.
nbmake: stopped in /var/obj/alt/obj/tools/texinfo/build/intl
*** Error code 1

[x68k/sysinst] なんか何やってもだめなんすけど。 頭悪いからかしら(正解)。 sysinst とはほぼ関係なくいつも通りの -current の build をしてみたら かなり早い段階で arc4random でこけた。 せっかく INSTALL カーネルに printf 入れて遊ぶのを思いついた矢先なのに これじゃ sysinst も作れねえなあ。 今週はここでタイムアウト。

[commit/3clause] そういえば先週、筒井さんから advertising clause についてのメールを頂いた。 偶然だけど、最近それとは全然別件で、BSD ライセンスの advertising clause て ちょっといやーんと思ってた矢先だったので、私の copyright がついている ソースからは外した。 でも sl811 関連のは何を思ったか The NetBSD Foundation の copyright に しているのでこれは自力では変更できないなあ。 まあそのうち誰かが跡形もなく書き換えてくれるだろうから(希望的観測) 頑張らなくてもいいか(汗。

[cvsup] [元ネタ] ここを読んでらっしゃる方から、うちではできてますが何か?(意訳) というメールを頂いた。あらら、やっぱ私が頭悪いのが原因なのね。

[MI/slhci] そういえば、見知らぬ外人さんから SL811HS/T での通信を安定させるにはどうすればよいでつか? (意訳) というメールが来た。久しぶりだなー、この手のメール。 それはねえ、あれを参考にせずに自分でドライバを書けばいいんだよ(汗。

今のソースはちょっとアレすぎだし、commit した後予想以上に 発展しなかったので 2.0 までに抜いといた方がいいんだろうか。

[x68k/build] 今週は libpthread あたりで syntax error でとまった。最近ビルド出来ないこと多いなあ。 とりあえず sysinst 試したいだけなので libpthread が 動かなくても知ったこっちゃない。コンパイル通るまで試行錯誤して誤魔化す。

[x68k/sysinst] 例によって力まかせで調べてみた。 なんか分からんけど mount(8) や mount_ffs(8) を実行すると sys/kern/kern_fork.c::sys___vfork14() がひたすら 呼ばれ続けてるのが問題なんじゃないかと思う。 sys___vfork14(), fork1(), exit1() に printf() を入れてみたところ。 sys___vfork14() と exit1() では l->l_proc->p_pid を 表示させてる。たぶんこれを呼んだプロセスの PID のはず。

# mount_ffs /dev/sd0a /mnt
vfork14 p=7
fork1 nprocs=9,max=84
vfork14 p=304
fork1 nprocs=10,max=84
vfork14 p=303
fork1 nprocs=11,max=84
vfork14 p=302
 :
vfork14 p=506
fork1 nprocs=84,max=84
vfork14 p=505
fork1 n>max!
proc: table is full - increase kern.maxproc or NPROC
exit1 p=505
exit1 p=506
 :
exit1 p=304

[x68k/build] 昨日の pthread_sig.c は今ごろ直したらしい。 つーか何の #ifdef もないところにただの syntax error 入れんなよ。 1回もコンパイルしてないだろ。 漏れみたいな素人プログラマじゃないんだから。

[x68k/sysinst] "popen reentrant (was Re: SA/pthread and vfork)" というサブジェクトのスレッドの話とは関係ないのかなあ。 英語読めないし意味も分からんけど、なんかこれ絡みで 1.6ZA に なったらしいのでまた update してみる。

[x68k/sysinst] と思ったけど diff とってもそれっぽいところに 変更がなくて案の定症状も変化なし。

[x68k/sysinst] ktruss 入り sysinst.fs を作ってみる。

# ktruss mount_ffs /dev/sd0a /mnt
   240 ktruss   execve("/sbin/mount_ffs", 0xffffccd0, 0xffffcce0) JUSTRETURN
   240 ktruss   eemul(netbsd)
   240 mount_ffs open("/dev/sd0a", 0, 0x2)         = 3
,_IOW('d',0x65,0x14)   240 mount_ffs ioctl(0x3, 0xffffcb00)          = 0
       "\V EW\0\0\0\0mydisk\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^B\0\0\0"
   240 mount_ffs close(0x3)                        = 0
   240 mount_ffs open(".", 0, 0xffffbee8)          = 3
   240 mount_ffs chdir("/")                        = 0
   240 mount_ffs __lstat13("mnt", 0xffffba38)      = 0
   240 mount_ffs chdir("mnt")                      = 0
   240 mount_ffs __getcwd(0xffffbee8, 0x400)       = 0
   240 mount_ffs fchdir(0x3)                       = 0
   240 mount_ffs close(0x3)                        = 0
   240 mount_ffs __sysctl(0xffffb9bc, 0x2, 0xffffb99c, 0xffffb9a0, 0, 0) = 0
   240 mount_ffs readlink("/etc/malloc.conf", 0xffffba04, 0x3f) Err#2 ENOENT
   240 mount_ffs mmap(0, 0x1000, 0x3, 0x1002, 0xffffffff, 0, 0, 0) = 68050944
   240 mount_ffs break(0x15f614)                   = 0
   240 mount_ffs break(0x160614)                   = 0
   240 mount_ffs break(0x161000)                   = 0
   240 mount_ffs break(0x162000)                   = 0
   240 mount_ffs break(0x163000)                   = 0
   240 mount_ffs __vfork14                         = 239
proc: table is full - increase kern.maxproc or NPROC
mount_ffs: vfork: Resource temporarily unavailable
   240 mount_ffs wait4(0xef, 0xffffbacc, 0, 0)     = 239
#

ちなみに普通に HDD から起動 (ただしカーネルは 1.6X で、ユーザランドは 1.6 くらいだったと思う) した場合の 1.6ZA の rescue/ktruss で rescue/mount_ffs を見るとこうなる。

yuka# ls -li /tmp
total 4560
75453 -r-xr-xr-x  2 root  wheel  2323640 Sep 15 11:14 ktruss
75453 -r-xr-xr-x  2 root  wheel  2323640 Sep 15 11:14 mount_ffs
yuka# /tmp/ktruss /tmp/mount_ffs /dev/sd1a /mnt
   344 ktruss   execve("/tmp/mount_ffs", 0xffffcba8, 0xffffcbb8) JUSTRETURN
   344 ktruss   eemul(netbsd)
   344 mount_ffs "/dev/sd1a"                       = 0
yuka#

[x68k/sysinst] これってカーネルの問題じゃなくて クランチバイナリの問題じゃないかなあ。mount_ffs 単体で 動かしたら ktruss 見てもソース見ても明らかに open(2) だの vfork(2) だの使ってないし。 ってもしかして、ちょっと前(/sbin がダイナミックリンクになった頃かな?) mount_* って個別に分解されたんじゃなかったっけ。 distrib/x68k/floppies/ramdisk/list 見るとハードリンクって ことになってるから、もしかして mount_ffs のつもりで mount を呼んでて そのせいであぼーんってなってたってことかしら。

てことで ramdisk/list を直したらあっさり動いた。 めでたしめでたし。ML に報告して commit しておこう。 久しぶりに勝利投手になった気がする...。

[Linux/hal91] 1FD Linux の一種で hal91 てのがあったので 使ってみた。ものすごいサイズの小さいバイナリがたくさん入ってた。 /bin/uptime とか300バイト足らずだったような。