蝉は、やがて死ぬる午後に気づいた。ああ、私たち、もっと仕合せになってよかったのだ。:2006年02月15日分

2006/02/15(Wed)

NetBSD/hpcarm + HP Jornada 710

@長いこと放置してありましたが

CFスロットにTYPE-IIを挿せるようにするカバーげとズザー。
master-corp.co.jpで注文すると無視されるか500 Internal Server Errorなので
mobileplaza.co.jp経由で注文すればよかったみたい。

@いくつか困ったこと

  • i386やhpcmipsでdisklabelしたディスクが"disklabel corrupted"と表示されてmountできない。
    これはmachine/disklabel.hに定義されているMAXPARTITIONSの値が古いのが原因。
    http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=18256
    のpatchを適用してbuildしたkernelを使うか
    http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/hpcarm/conf/INSTALL_IPAQ
    をベースにJORNADA710/720用のinstall kernelを作ってsysinst経由でdisklabelすることで回避してちょ。

  • 再起動するとHPロゴの初期画面で液晶が真っ白になってハングアップ
    WindowsCEで使ってても時々この状態になるのでハードが腐ってる気がするけど。
    他の個体だとどうなんだろうね。
    この状態になってしまったらリセットボタンも効かないので、バックアップ含めてバッテリを外す。

CP936(GBK) iconv data

0x8180~0xFEFEがごっそり抜けてるので直した。
ついでにGB18030もiconv(3)でまともに使えるようにしたいんだけど
mkcsmapper(1)に喰わせるソースに

SRC_ZONE 0x8181 - 0xFE39FEFE

とlinearで定義するとテーブルが巨大すぎてmalloc(3)コケる件が放置中なんよね。
mkcsmapper(1)のalloc_memあたりを直すつっても、どっちみちlibcの中でも同様に困る予感。

TYPE ROWCOL
SRC_ZONE 0x81-0xFE / 0x40-0xFE / 8

のように区点で宣言してテーブル容量を節約する機能もあるんだけど、CNS11643のような面を持つCCSや
GB18030のような4byteコードの場合には使えない。

以前ISO-2022-CNとEUC_TWをサポートした時は、CNS11643の面毎に別ファイルにして
お茶を濁して逃げたんだけど(citrus_iso2022.cのwctocs/cstowcに手を入れずに済むし)
GB18030の場合はどしたもんかいね。

GB11383(ASCII)、GB2312-80、 GBK、 Unicode BMP + 1~16面にバラしても
まだ将来拡張領域48万字のエリアが残ってるし、Unicode互換領域っても非連続なので
citrus_gbk2k.cのwctocs/cstowcに4byteコードをUnicodeに変換する処理 (テーブル)を積んだらそもそもcsmapperは必要なくなるという罠。