アクマくんにお願い:2000年02月下旬

... \

練習してみる.... うーん、さすが10年以上全く弾いてないとダメダメです。 すぐに左手の指が痛くなってしまった。情けない。 ちゃんと押さえきれてないから弦はブレるし、 指の位置がおかしいので隣の弦に振れて消音しているし。 おハコだった「スカボローフェア」も、 コードも完全に忘れているし、 右手の指の運びもあやふやになっている。 譜面とか、実家に帰らないとないだろうなあ。 帰ってももうないかも。

... \

逆に「はにゃーん」とか「ほぇー」とか言わない人なら 結婚できるかと言うと、全然そんなことはないと思います。 何らかの相関はあるかもしれませんが、 結婚できるできないは、多分違うところにあるのではないかと。

それから結婚後に壊れる分には問題ないかというと、 もちろん問題ありありです。(^^; きっと相手にもよりけりでしょう。

いつもかわいい絵をありがとうございます。 沙樹ちゃんかあいいです。 いつもは黙って絵を拝見させていただいてるだけなんですけど、 お世辞抜きによく描けていると思いますので反応してます。

この服(りぼんも)好きには、全くその通りというか、 司くんの「普段からそういうかっこしろよな」(だっけ?)に 思いっきり賛同したくなります。 性格的にはこの人が一番好きなのですが、そういう人は多そうですね。

単行本は実家に帰らないとないので、文庫を買おうか悩み中。

それは「お約束」というものだと思います。 お約束は、守らねばなりません。:-)

関西方面から、メールで反応をいただいた。\

今月号は買わなくていいかなと買わなかったら、 未だにブツを送ってくれる気配がないんですが、 どうなってるんだろう??

.

九段のうどんやさんで、某打ち上げ。

新宿局の消印 18 日で、今日届いていた。 住所も郵便番号も正確に記載されてるのに、何やってんだろう? > 郵政省

NetBSD 的にはとりあえず、 (http://mail-index.netbsd.org/tech-kern/1999/05/)から 5/16 の "Ideas about the cdevsw/bdevsw structs." のスレッドを 要参照ってな情報をメールでもらったり。< 遅刻大明神

FreeBSD の make_dev() はドライバが己の major 番号を知っていることが前提で 設計されているのではないかしらん。 これはもちろん、3rd party ドライバを考えればよろしくなくて、 ドライバじゃなくてフレームワークが major 番号を管理する必要があるでしょうね。 結局、dconfig ちゃんとやるには 「どうやって manjor 番号割り当てるの問題」 に答えを出す必要があるわけですが。

それから、devsw というか major number は device instance ではなくて、 driver に対応するものなので、 そっちの観点からもドライバが attach で自分で登録するスタイルよりも、 フレームワーク側で面倒を見てあげるスタイルの方が 適切と言えば適切かもしれないなぁ。

小鳥さんお疲れさまです。:-)

まず、{b,c}devsw のある sys/arch/ARCH/ARCH/conf.c だけど、 歴史的に見れば (old) config(8) による autoconfiguration よりも {b,c}devsw の方がずっと由緒正しいでしょう。 もちろん、現代的視点で見れば柔軟性のない困った実装です。

major 構文が config(8) に必要になったのは、 おっしゃる通り root/swap/dump の各デバイスが何なのかを config(8) が知るためでしょう。 だから現在は bdevsw にしか使われていませんね。 結果として、major 番号に関するオリジナルが分散されて気持悪いわけですから、 major 番号の関する情報をどちらかに寄せようというのは、ごく自然ななりゆきなのでしょう。 この場合、生成されるべきは devsw だけではなくて、MAKEDEV (or devfs) も扱えないといけないでしょう。 どちらに寄せるべきかという点については、 newconfig 的にというか hard-coding よりも data driven の方が優れている、 という結論になるのではないかと思います。

devsw_addのような、動的に {b,c}devsw に登録するメカニズムは はどっちにしろ必要だし、 この際だから一歩進めて{b,c}devsw を抽象データ化してしまうというのも 考えられないでもないと思いますが、 実装自体は難しいものはなにも無いと思います。 手間もたいしたことは無さそうです。 現在の FreeBSD 式 {b,c}devsw_add は major 番号を デバイスドライバが知っていることを前提にしているので、 3rd party によるデバイスドライバの追加を考えればよろしくない、 程度の話であります。 もっとも devfs をちゃんと完備した上で、 3rd party への major 番号の割り当てポリシーをちゃんと確立しておくか、 {b,c}devsw_add に major 番号の自動割り当て機能を加えれば、 FreeBSD 方式でも悪いわけじゃないとは思います。 ...これも new-bus 流儀の匂いがしますけどね。 config(8) のような userland application が知っていれば MAKEDEV を 同時に生成するようなのは簡単だけども、 カーネル中の関数だけで解決しようとすると、それが難しそう。

一方、files ファイル中に全部 major 構文で指定しまう方法に問題が 無いのかというと、それでも 3rd party への major 番号の割り当てポリシー問題は残るわけで、 major 番号衝突してる場合にどうするかとか考えないといけないでしょう。 大明神様からのメールによると、 3rd party driver も newconfig 的にはテキストファイルな files.* を持つのだからユーザーの責任で管理すれ、ということらしいです。 私としては、デベロッパーはともかくユーザーに files.* に 関して関知させるのは避けたいですけどね。 一つの手としては files ファイルの major 構文を config ファイルで override できるようにしておくとか、 あるいは、"major {joy = ?}" てな構文で システムが空きの major 番号を自動的に割り振るようにして 3rd party driver はもっぱらこれを使うべしとするとか、 いう方法もあるかもしれません。

あれ?これって東上線だけかなぁ。 私は慣れているので、ごく当然に思ってましたが... 営団とかも発車ホーンとか鳴らしてましたっけ? (営団は列車によってはドアが閉まる時に自動的に列車内で警告音を 出す車両はあるみたいだけど) あ、東上線でもさすがに人が挟まったら、 やっぱり一旦ドアを開けてくれると思いますが、 そうじゃなかったのかな。 ちなみに、朝のラッシュ時間帯に限ってはさすがに発車ベルを鳴らします。

はは。はははは。 sos も phk も core だろ? えーい、止めたやめた。 もう motivation 尽きた。やって報われないことは、したくない。

newconfig の主要メンバーが揃って FreeBSD 捨てちゃうのは よろしくないだろう、 scsi_low の CAM 化はやろう、 あるいは PAO の merge はやろうと思ってたんだけど、 全部やる気がすっとびました。 もしこのあたり期待していた人がいらっしゃいましたら、 大変申しわけありませんが、 無償で作業しているものゆえ、 motivation がなくなれば、もう手も足も出ません。 ご理解ください。

お掃除モードに入ります。 とりあえず、作業できている esp の pccard だけ nomads に投げて、 当面の間メンテナンス以外の開発はしないと思います。

_ 追記

う、この書き方だと金輪際 FreeBSD を自分のマシンから uninstall して 使わないように見えるかもしれないけれども、 そういうつもりはありません。 kernel のコード書いても、このあたりの人とは技術的に communicate する 自信が完全に喪失したので、開発は止めるというだけです。 1ユーザーとしては続けると思いますし、 userland の作業ならするかもしれません。 でも、開発に必要な ML はもう読まないつもりです。

TDS を 1.01-beta0 に上げたついでに、 いろいろ体裁をいじった。CSS についてちょっと勉強。 なるほど。ダメだね、ネスケ。

tf さんの UNIX でもできるリーフなゲームのページですけど、2ヶ所ほどローグじゃなくてルージュになっているようです。

「分かりやすい表現」の技術
講談社ブルーバックス B-1245
藤沢 晃治 著
ISBN4-06-257245-1

痛いです。大当たり。 というか、職場に置いとくことにしました。 騙されたと思って、読んでみるべし。