![[logo]](/images/suz.gif)
ぐるぐるこめんと ぐるぐるこめんとなぜ、壁紙パッチを取り込まないかというと ...
というのが一応 メインの理由、API っていったん決めると 変更することが
できない .. という感じになっちゃいます。
だから バックグラウンドのスクリーンの実装は取り込めるんですが、
API は、ちゃんと考えないといけない。
mgterm が いろいろなライブラリを直接リンクするのは、ポリシーに反するからダメ。 だからといって、適当なローカルフォーマットに 対処するには 読み込み終ったらファイルを消すとか そういう面倒な 手続きが必要になるし...
というわけで、mgl のテキストのイメージフォーマットを
tty に送り込めばいいじゃんとか 考えて API を作ってみたんだけども。
遅いという問題あり、さらに致命的な問題がある。
... open_graph 呼ばないと既存のコードが使えない。
いまあらためて考えてみるといくつか、案がある。 とりあえず メモレベルですが列挙
■ 有野さんところで、 キャッシュカーネル の話題が ...
キャッシュカーネルとは なに？ というのが気になったので調べてみる。
要するにこういうことか。nano カーネルとか言われていた Mach の改造版と なにが違うんだろう。たとえ かなり整理されていたとしても、 機能レベルでは、いまさら メリット感じないような気がする。 いまの モノシリックカーネル って kernel thread もてるし...
まあいいや。とりあえずメモしておこう。
■ Omicron:プロセスの呪縛 を見て
むこうのページに書かないと 卑怯という気もするんだけども、 とりあえず持論書いてみるだけだから。
まあ、実際に困るのは、グローバル変数の name space と リソースの後始末？
dlopen してモジュールを読み込むのを前提にすれば、 グローバル変数は実際には衝突しないような気もする。
リソースの後始末は、まあ ちゃんとしていない方が悪い と考えれば良いか。
あとは、何だろう。mgterm だと root の権限もっていたら、いろいろ やっているなぁ。これらができないってのが プロセスの呪縛ってことかなぁ。
うーん。これはどうなんだろうか。fork() というものは、コンテキストの コピーを必要とするから、実装の制限ができてしまっていてマズイ。 というのは理解できる。thread の create みたいに、関数指定の方が良かった。 ただ、その実装は難しいような予感。理由は、context を壊せないから、 fork を呼ぶまでに使った スタック上に リソースがあるし ... たぶん、空いているのが明らかな リソースは、スタックだから、 コンテキストをコピーするのが楽な実装かも。thread を作ってから fork するなんてことを考えると、それはそれで 困った点ができるかも。 --- thread をサポートしなければ、プロセスが実装できない。
それ以外の話については、どうだろう ... POSIX のモデルの上に構築できない 点があるのかなぁ.. 一応 java VM みたいなものを作ることができるのなら、 プリミティブとして 不足している点はないんじゃないかという気はするけど。
む、 VM はつくれても、その外との関係が問題だっけ？ たとえば java VM を fork するなんてことはできないとか ..
プロセスまたは、プロセスのグループ を checkpoint して、再開する
とか、dup して 後で動かすとか
みたいな機能を実際に考えてみると、いろんなところで 問題が出る。
そういった問題と同値じゃないかという予感。
ちなみに、checkpoint して、再開するときの問題は主に リソースの再獲得
でも こういうのが難しいのは、UNIX だからというわけではないような ...
あと、checkpoint をどうやって実装するかというと...
たとえば linux では、かなり 詳細に /proc/pid で プロセスの状態がわかる。
これを ファイルにセーブして、起動後同じ状態にするようなことを考えれば
たぶん良い。
だいたいは、再現できそうなんだが、やっぱり上で出て来るものが
再現できなさそう。
あれ? ずれたこと書いているのかな?
もともとは、コマンドを実行するだけなのだから、 ちゃんと fork して リソースを安全な状態にしてから exec するのが面倒 ... だから fork はいらない。
ってことだっけか。
確かに Thread 環境で ちゃんとfork するのは面倒なんで、
fork + exec の機能を 代替する プリミティブはあってもいいように思います。
ただし、fork と exec の間でやれることは、どうしても制限せざるを得ない
。あたりまえですが...
pipe の接続のサポートは たぶん欲しい。他にいくつかやりたいことが出てきたら とても汚い インターフェイスになりそう。
うーん。linux の /usr/lib/libc.a とか nm すると
w __pthread_atfork
なんてのが山ほど出て来るなぁ。
OSが空っぽでフラッシュからブートするPDA
PDA系のOSパーソナリティ
で、そういうプロセスって 普通のOS の上でも動かせそう。 カーネルは、初期化が済んだら main 動かして あとはライブラリcall で サービスするようなものになるのかなぁ。
仮想記憶はできた方がいいかな。mmap とか使えるし。
で、どういうプロセスを動かすのだろう？ 私的には、ブラウザ + httpd スレッド とかで十分という気がする。 そして、httpd がファイルシステムのかわりをするなら、 native なファイルシステムは 確かにいらないかも。
native なファイルシステム持っていていも同期の問題があるから それだけでは、あまり役に立たないような気がするし...
なんか いろいろ考えていくと、 java 的なもの になってしまう。 下位レベルをどう構築するかなんて、実はどうでも良くて 構築するものが やっぱり重要ってことなのか。
■ PDAとOSその２
上のようなこと考えて、実際にモノを作ってみるのを はじめてしまっている わけですが....
Omicron の Omicron:Unix その他のページで 反応が...
なんか、大風呂敷になってきた ... ほんとうにできるかなぁ。
それはともかく、いままで、ファイルシステムというのは 複雑なだけで 面白みのないもの ... とか思って来た。実際に いじってみると かなり 面白い。
あ、ruby で サーバ作る テンプレートは、sample/tsvr.rb か わずか 20 行。簡単にできるものだなぁ。
HTTPD は、sample/dualstack-httpd.rb か こっちも 55 行と小さい。
まずは、dualstack-httpd.rb を動かすことを考えてみると よさそうだ。
TikiGuion:GC とか Omicron:キャッシュとかみて思うこと。
ずいぶん前に Tiki:GC とかで、キャッシュ == 主記憶の関係 とか 話題にしてみたんだけど も、いまどきのファイルシステムに求められるもの も 主記憶 == ディスクの関係が 中心になっている。で、 PDAのコンテンツ とか考えだすと、ファイルが 情報の実体じゃなくて、 ネットワーク上にあるものが 実体と思えてくる。
こんな感じ。
レジスタ == キャッシュ== 主記憶 == ディスク == ネットワークリソース
で、それぞれをつなぐ パイプってのは、どんどん太くはなるんだけども、 ( レジスタ == キャッシュ は別にして ) 扱える or 扱っているリソース量を基準にしたら、 相対的には細くなる傾向があるんじゃないだろうか。
さらに、パイプの長さ(アクセスのためのTAT) は パイプの太さ (スループット) に対して やっぱり 長くなっていっている。
(根拠はともかく)自分の中ではそういうことが明らかで、 ソフトウェアの構造とかを変えられたら もっと高い性能を享受できると 思っています。... 逆に言うと ソフトウェアの構造がボトルネックになっていて、 ハードが進化しても、さほど性能が上がらないとか。
＃ところで、違和感が拭えないってどういう意味だろう？ 釈然としないということかなぁ？
あと、ページ について、よく使われる メモリの保護の単位はページだけども、 これも 大きくなる方向。IA-32 とか 4KB だけども、IA-64 とかは、16KB が標準。 実装メモリが 128GB くらすになれば、64KB にしたいところ。 計算すればわかるのだけれども、128GB って 16KBページなら、8M 個のページを 持つことになる。ページテーブルのエントリ(PTE) は 64bit だから、 8バイト。ページテーブルが 64MB にもなってしまう。
これだけのリソースを扱うのは、おもにカーネルの責任で、カーネルは、 1 ページあたり 100 バイトぐらい のリソースをつかっている。 8MB 個なら、800MB。
このデータの(全部またはその何割か) を定期的(秒オーダ)で、スキャンするのは 現実的ではないから、せめて、1/4 -- 64KB ページにしたい。
(正確でないけど) だいたいこういう論理で、ページテーブルは だんだん大きくなるはず。
なにがいいたいかというと、可変長のページ？ を扱えるCPU だとか せめて小さな単位のページを扱えるCPU があったとしても、カーネルは たぶん それをサポートできない。(だから そういうCPUは作られるはずがない)
Omicron:ワンレベルストアとかもどうなんだろうか、個人で 100GB レベルの ストレージもっているわけで、すでに 32bit を 5bit 越えている。
ちょっとした大規模システムとして、だいたい この 1000倍ぐらいを考えると 100TB 。で、32bit + 5 + 10 = 47bit 。 64bit まで、あと 17bit 、64bit では、20年もちそうにない。
あと、IA-64 とか 64bit までフルに アドレッシングできることを考えてなかったような 気が ... そうすると 寿命はもっと短いかも。
なんか、64bit ではイマイチだし、128bit を考えないといけないのかも。 ついでだから、md5 でハッシュして、それを空間の ID にするとかすると 面白いかも。
とりとめがなくなってきたので、このへんで。
有野さんが、 gcc移植 やってみるそうな ...
おもわず反応。いつだったか ある アーキティクチャ向けに 自分で 移植 やってみたことがあります。当時は、gcc-1.41 で、gas と gcc と binutils と libc を build した。結局 hello-world を printf できるところまで確認した ところで、致命的 問題 (設計ミスですな) に気が付いて おしまい。
その後、新人の教育で gcc-2.x の port をやってもらったこともあったりして。 そのとき得た情報
あとは、PIC まわりは なにかと面倒かも、PIC なんぞ知らないという立場 だったので、詳細はわかりません。
Gmicro とかのCPUはまだサポートされてるのかな？サポートされているとしたら誰がメンテしたり 動作確認をしたりしてるんだろう？
有野さんが、 gccのデバッグ までたどりついたそうな。
cc1 が出来ているはず。cc1 は C から アセンブラに変換するものなので、 C のソースを食わせてやって、どういうアセンブラに変換されるかやってみる のが良いと思います。
最初は、簡単なもの。たとえば、
int foo(int a) {
return a*2;
}
とか。最適化 あり/なし とか いろいろ やってみる。 md の 内容はともかく、一通り揃っているなら、internal error にならずに なんか出て来るはず。
次に だんだん 高度な コードを試していく。なんでも良いから、複雑そうな コードに対して cc -E とかで プリプロセッサ通したものを用意して、 それらしいものが出て来るかどうか確認。私がやったときは dhry.c (ドライストーン) を試しました。
なんか出て来ると試したくなる.... 実際にどう試すかは、 もっている環境によります。シミュレータ (実用として命令エミュレートをしないケースはエミュレータとは呼ばない..はず) とかがあると便利ですが...
むう、 virtual_memory_exhausted ですか。
そういうことがおきた記憶はないのですが... md の定義が循環しているとか
たしか、生の RTL を出すオプションがあったと思うので、それを出してみて、 どう変換されるはず ってのを考えていくのかなぁ。
生の RTL も出ないのであれば、md とは違うところ... レジスタの定義とかの 問題かも。
実は、半年ぐらい前からお気に入りのマンガは、ベルセルク だったりします。
ベルセルク .. 全然知らなかったのだけども、 なんとなく気になって、マンガ喫茶で手にとって いきなり全巻読破。 自分でも 全巻 揃えてしまった。
それから、ヤングアニマル買うようになって、 エアマスターも 気になりだして、 マンガ喫茶で全巻読んでしまった。
ちなみに、全巻揃えたマンガは スラムダンク、バスタード、ドラゴンボール 、 花の慶次 、ベルセルク の 5 つ。
有野さんの 働く目的 ... 興味深い。コメントはなし。まぁ このテーマについてはゆっくり考えてみたい。
桜ケ丘行くなら
スクェアというビルの中にあるマサラという カレー屋 さんは お勧め。
(私の記憶では)
ネパールのカレーで辛くないのが特徴。辛いのが好きな人のために 唐辛子の粉末が
おいてある。
3時か4時までバイキング(飲み物1つつきで 880円)
というメニューがあって ナンたべほうだい。
やはり 手遅れ でしたか。まぁ、もしまた行くことがあったら、試しにどうそ。
チャイ、アイスチャイという謎飲み物があったりします。
あと、ネパールのはずなんだが、客にインドと言われても、店員は否定しない。 ひょっとしてネパールというのが間違いで、単にインドの北の方かも？
ちなみに、おすすめしているのは、見るからに商売がへたで、 つぶれかけたようだったから。最近はそうでもないようですが、一時期は 本当に客がいなかった。
政治的にただしい ... ふうむ、そういう経緯から そういう結論に達するケースもあるわけか。
というのが、私の行動の規範の1つですが、いわゆる良識から来ているわけではなく、
単に論理的な結論だったはず。... でも どういうことだったか忘れてしまった。
まぁどうでも良いことですが。
示唆に富んではいると思いますが、ことなかれ主義に陥る可能性大です。
ゴミ捨てにしても、ポイ捨ては論外として、分別まで要求する人もいれば
ゴミ箱に捨ててればokの人もいます。人それぞれなわけだからうまく大勢を納得させればよし。
政治的に正しいかどうかを決めるファクターはいろいろあります。とにかく人は
見ていないようでよく見てますからね。恐いですよ。
そういう目を意識しながらどこかで落しどころを探すってことがポイントだと
思います。そこでは敗けても全然問題なし。負けるが勝ちという言葉もあります。
--ksr
戯もお邪魔しまーす。そーっすね、事勿れが心配っす。 "されたくないことはしない"のほうがむしろ論理的に変(ぉ)だと思ってます。 なぜなら、それを(全面的に)肯定すると、集団の行動パターンは単に 各個人のそれの論理積になっちゃって、凄く狭いモノになるので。 政治的正しさってものは"それ(だけ)では面白くもなんともない"ってのが最大の欠点かなと。 いかに拡張(拡散ともいう?)するかが関心事だなあ。
うむむ。うまくいえんですが、 企業においては自分の勝負する分野以外でことなかれ主義なのはそれ程問題では無い気も--有野
うーん。なんか誤解をあたえてしまったようです。私の出した2つの話は、 政治的にただしい の話の内容についてのコメントではなくて、 良識というもの から導出されたものじゃないという 点についてのみのコメント。
で、上の2つの話を内容にリンクしちゃうと変なことになります。
あと、誤解のないように書いておくと、これだけが規範ではないわけで... 単に行動を規制する 規範の1つ。しかも実際守れないような状況もあったりするから ポリシーととらえてもらっても良いかも。
たとえば、仕事なんかで、 (自分が)されたくないだろうなぁと思えることを 人に強制することを、 (たとえば上司から)強制される場面があったりするわけですが、 こういうときは、かなり頑固に反対しています。幸せなことにわりと通ったり しています。
あと、これのみが規範だと考えると、それはそれで問題です。 仮に 私が "人から裏切られたくない" とは思っていないとする。 (仮にですよ、仮に) この規範では、"人を裏切ってはいけない" という結論にはならない。 もし、それがやってはならないと考えるなら、別の規範で ということ。
ということについて。
社会的に正しい行為== 良識というものとすれば、
ということになるわけです。
で、他人から良識というものを根拠として、私の行動の問題を指摘されたと すれば、たぶんいかなる根拠でも反撥することになるでしょう。 (行動を正すには、良識以外の納得いく理由が必要ってことです)
基本的には、そういうことを指摘されないように行動するわけですが、 良識を持っているためではない。