自分とこのdevブランチにあるFUJIMI-IM/sj3なんだけど…OpenBSD上でsj3(tty client)を動かすとなんかエラーメッセージがちゃんと見えるのが謎。画面下のステータスラインはEUCで来ているの(で化けるの)に、なぜエラーメッセージをUTF-8な日本語で表示する…?どこかでUTF-8への変換なりUTF-8でのメッセージを持っていたりする??
OpenBSD, Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
自分とこのdevブランチにあるFUJIMI-IM/sj3なんだけど…OpenBSD上でsj3(tty client)を動かすとなんかエラーメッセージがちゃんと見えるのが謎。画面下のステータスラインはEUCで来ているの(で化けるの)に、なぜエラーメッセージをUTF-8な日本語で表示する…?どこかでUTF-8への変換なりUTF-8でのメッセージを持っていたりする??
(USBストレージからのブートにも限界はあるし、そっちはそっちでOHCI/UHCI/EHCI→xHCI対応が要るし。)
(Legacy IDE→PCI-IDE→AHCI→NVMeに追従できないだけでPC/AT互換機上のOSは動かなくなる…と、都内某所の方角を眺めながら呟いてみよう。ああ、今はBIOSじゃなくUEFIだからその対応も要るか。)
古いドライバのコード、メンテ出来なくなったらもう切ってくしかないよな…ISA系とかばっさり、PCIですら切るものが色々出て来そう。
Linux Ethernet-HOWTOで、3Comの買ってはいけないチップが書いてあったよなーという記憶があったんだけど、3c501か。 http://archive.linux.or.jp/JF/JFdocs/Ethernet-HOWTO-5.html
errataに関する情報が取れないと、イマドキのデバイスは怖くてドライバ書けないですよ。NDA結べば情報とれるっていうならまだマシで、そんな情報すら取れないのが普通だし…(だからLinuxや*BSDのコードを見るしか無くなる)
このアカウントは、notestockで公開設定になっていません。
AT&T UNIX System V Release 4を試用する (2022-08-07)
https://debslink.hatenadiary.jp/entry/20220807/1659798257
うーん、そこまで遡る必要が(自分にとって)今あるのかどうか…(悩
というか、Am79C970AですらNICの認識をできないとなると…何なら認識してくれるんだろうか。NE2000か3C905って話があるんだけど(だとしたらVirtualBox/VMwareでなく、QEMUでやれって話にならんか…?) https://forum.vcfed.org/index.php?threads/unix-for-a-486.35335/
OmniOS(CE)、/sbin/haltじゃなく/usr/sbin/haltですと…?!
Kindleでも買えるらしい
はじめてでも安心 コスプレ入門 (2011/11/23) https://www.amazon.co.jp/dp/4274068617
オッサンはAgon(eZ80)みたいなネオレトロなハードとか、マイコンで遊んでなよとか言われそう…
とはいえ、仕様書を見たら見たで頭抱えそう。昔よりも今のデバイスの方がさらに複雑怪奇になってるだろうし。
今のお仕事って(お察しください)なんですけど、扱ってる品物によっては情報を持ったヒトがお店にやって来るなんてこともあるので…ほんと扱いが違うよねーって思いました。まあ、扱っている品物が品物なのと、業界がそーゆうところ(文化?)というのはあるんでしょうけど。
高品質なドライバを書きたいなら、デバイスの製造元に勤めるとか入り込むしかないというのが自分の経験上言えることかなあ。
サードパーティーやってると、製造元からの情報提供には限界がある(というかほぼ無いことの方が多かった)以上、Linuxとか*BSDとかのコードを参考にするなどして劣化コピーを作るしかないというのが…
ハードウェアにとってデバイスドライバは補完財なので無料で配る動機はあるがそれ自体が収益を上げるわけではないので、もしかするとデバイスドライバ部門がコストセンター扱いされて待遇がいまひとつだったりするのかもしれない
UNIXを教科書読んできちんと勉強したって記憶が…ないw
Run Run Linuxでインストールして、あとはいじりながらという気が…(なのできちんとしたUNIXのプログラミング作法、実は知らないんですよ、google頼みでコードいじってます)
これは…確かに人によっては必要になるのかも。相当ニッチな領域だけど。「BSD系UNIXシステムなどからSVR4に移行したシステムプログラムにSTREAMSに関する詳細で深い知識を提供する実践的参考書。」
詳解UNIXネットワークプログラミング (ADDISON−WESLEYプロフェッショナルコンピューティングシリーズ) (1995.10発行) https://honto.jp/netstore/pd-book_01218612.html
ほうほう。「NEC EWS4800シリーズ対応、SVR4.2の入門書。歴史的な解説や機能の説明から、日常の操作、システム管理・運用まで、基本をていねいに解説する。必要や興味に応じた読み方ができる。」
UNIX SVR4.2システムガイド (1994.5発行) https://honto.jp/netstore/pd-book_01060209.html
すごいなあ。「いまやUNIXはSVR4系が主流。しかし、長年BSD系UNIXを使い続けたユーザーには、移行に対する戸惑いとためらいがあるはず。そんな悩みを一挙に解消してくれるガイド。」
BSD TO SVR4移行のための徹底ガイド (Ascii books) (1995.7発行) https://honto.jp/netstore/pd-book_01207036.html
自分が大学1年(1994~1995年)の頃、サーバ構築はSVR4で決まりでしょ、みたいな空気があったような気がしたんだけど…あれから30年。SVR4の影も形もなくなるくらいLinux一色になってしまったよなあ。
ハードウェアメーカーはハードウェア仕様書を公開して各OSの開発者にデバイスドライバを作らせて(?)
NetBSD/SONY-NEWSって、SONYの人達はどれくらい協力してくれたんだろう?LUNA向けの移植は結構OMRONの人達が協力的なように見えるし、Wnnとかもまあ積極的なのかなーって気がするけど(※根拠なしの個人の印象です)。PlayStation向けのLinuxとか見てると、なんかお塩っぽいのかなーとか思ってしまう。実際どうなんだろうね?
なんかあれだよねー、こういう古いコードをいじるときのために当時の環境がそっくりそのまま残っていて自由にアクセスしてね!なんて感じのラボがあったらいいのに。コンピュータ博物館みたいなものが担うんだろうけど…まあ、将来においてそういうのができたらいいねって気はするけど動態保存も難しいだろうし。
SVR4のコードはもう無条件に切るか…とはいえ、__sony_newsの絡む部分については問答無用する訳に行かない箇所があるからそこは要注意なんだけど、ヘッダとかはざっくり行ってもいいかな(どうせ、無いので)。
流石にSolarisの血を引いているだけあって、/usr/include/xti.hにt_open()他TLI/XTIの定義がある。OmniOS CEにbuild-essential突っ込んだだけでこうだから…ああ、sys/euc.hもある。
売り物の環境(Solaris)なんかだとSYSVが定義されているのかなあ。なんとなく、SVR4なコードもばっさり要らないと切っても良い気がするんだけど。(NEWS-OSにBSD系とSVR4系の二つがあるという理由でこんなコードになってるんじゃないかという気がしてる)
#define __GXX_ABI_VERSION 1017
#define __GCC_HAVE_DWARF2_CFI_ASM 1
#define __DEC_EVAL_METHOD__ 2
#define __VERSION__ "12.3.0"
#define __GCC_CONSTRUCTIVE_SIZE 64
#define __STDC_VERSION__ 201710L
#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
#define __GNUC_PATCHLEVEL__ 0
#define __GCC_DESTRUCTIVE_SIZE 64
uaa@omnios:~$
uaa@omnios:~$ echo |gcc -dM -E -|grep V
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __FLT_EVAL_METHOD__ 0
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __FLT_EVAL_METHOD_TS_18661_3__ 0
#define __HAVE_SPECULATION_SAFE_VALUE 1
#define __SVR4 1
(つづく)
ん-、Windows上のVirtualBoxでもなんか安定しない。とりあえずCPUを1個とすると起動するけど。なんなんだろう。
Linux上のQEMU/KVMだとなんか動かないことがあるんだけどOmniOS CE…Windows上のVirtualBoxでやるか…
ん-、VMwareじゃなかったVirtualBox上に一旦インストールして、v2vするか…?
https://gist.github.com/sjorge/4319f87f6eebc1540c91
https://blackdot.be/2014/09/omnios-and-serial-console/
https://wiki.freebsd.org/bhyve/OmniOS
…地味にめんどい?
OmniOS CEを落として何をしようとしていたんだっけ自分。多分sys/euc.hの有無とかその辺の確認という気がするけど。
そもそもこれ、シリアルコンソール越しに動かせるようインストールするとかできるはず…だよねえ?
infocmpが現在使用中の端末に関する情報、infotocapがterminfoを解読してくれるものということになるか…tgetent()の説明によればterminfo使っててもtermcap使っているかのようにエミュレートしてくれるとある。
このアカウントは、notestockで公開設定になっていません。
Emacsを起動しようとしたらtermcapが見付からないと言われる 2007-07-01 https://kuenishi.hatenadiary.jp/entry/20070701/1183229763
確かに/usr/share/terminfoにまとまってるけど…バイナリじゃんこれ。どう読むんだろう。
あー、termcapって端末向けに「こういうの送って初期化しますからねー」って情報をまとめただけの物なので、これ自体が何かをする訳じゃないのか(端末が何かをするので)。なのでlibcursesを見たところでi1だのisだのの二モニックしか書かれてないのは当然か。定義方法だけあれば良いんだし、と。
https://android.googlesource.com/platform/external/ncurses/+/refs/heads/llvm-r416183/include/Caps#796
リセット文字列がr1, r2, r3とあって、r2が無ければrsが参照される。
r3が無ければi2がr3として扱われる。SystemVにおいてはisがi2となる…という理解で良いのかな。
termcapを見るに、wyseの端末はi1もi2もisもあるな。
https://nxmnpg.lemoda.net/ja/5/termcap の説明では、
init_1string i1 初期化文字列
init_2string is 初期化文字列
init_3string i3 初期化文字列
termcap_init2 i2 2番目の初期化文字列
どれがどの順番(どういう優先度)で動いてるかが謎だな。
とはいえ、mbstowcs()、sj3内部のwchar16_t使う奴じゃなくシステムのロケールを反映するwchar_tの方に置き換えたいという可能性もあるから…あんまりいじらない方が良いのかなあ。
sj3、とりあえずいじれるだけコードをいじってる版(PRしていいかどうか分からない版)は https://github.com/jg1uaa/sj3/tree/dev で作業中。
今のところfix, sj3, sj3-ansiブランチを統合して、TLIのコードを抜いた内容になってる。できればSVR4も外したいんだけど、その時点でmbstowcs()絡みの問題にぶち当たったところ(これもSVR4の有無で変わるので)。
wchar16.hにあるmbstowcs()→sj3_mbstowcs()の類、これdefineせずに直接呼ぶ方が良いんじゃないかなあ。<stdlib.h>にあるmbstowcs()を呼んでるのか、sj3側呼んでるのか全然分かんなくなるんだけど。
あー、しくじったかも。
Google code版のSJ3、kanakan.h, server.h, sj3.h, sj3dic.h, sj_func.hの5つのヘッダに必要な関数を書いていたみたいだけど…sj3.hを魔改造+sj3priv.hを新設してしまったのでどこかで再編しないといけない。
CFLAGS="${CFLAGS} -g -Wall -Wno-pointer-sign -Wno-unused-parameter"
PR投げる用に、fix, sj3, sj3-ansiにブランチ分けてるけど、なんかこれ統合したのをいっちょ作っといた方が良い気がしてる。ていうか統合したのをPRで投げちゃった方が良いのかな(結構な量になるので実はセクションごとに分けてた)
H8/SuperH/M32殺しといてRZ(Arm)に浮気し、そしてRISC-Vとはなんと節操のないR社…!(伏字になっていない)というのが率直な感想。