タグ

plan9に関するyuguiのブックマーク (15)

  • ホワット・ア・ワンダフル・ワールド なぜ Inferno/limbo は重要なのか (Why Inferno : Compact Multi-Platform Distributed OS and limbo programming language matters ?)

    なぜ Inferno/limbo は重要なのか (Why Inferno : Compact Multi-Platform Distributed OS and limbo programming language matters ?) 端的に言って,プログラミング言語だけ,あるいは OS だけ,あるいはライブラリやフレームワークだけを研究するということはナンセンスなのである. なぜ UNIX は成功したのか,C は成功したのか ? それは,UNIX 自身が C 言語のプラットフォームであるとともに,C のライブラリであり,C は UNIX を実装するために設計された言語であったからだ.全てがひとつの 「システム」 の構成要素であり,どれ一つ取り外せない循環を成している. では,なぜ UNIX は駄目なのか ? それは端的に言って,時代の宿命である.UNIX は優れた設計思想を持ってはいた

    yugui
    yugui 2007/04/14
  • XCPU - Plan9日記

    PCクラスタ,グリッドコンピューティング関係の国際会議CLUSTER 2006で,Ron Minnich氏がXCPUについて発表した.タイトルは「XCPU: a new, 9p-based, process management system for clusters and grids」. XCPUは9Pプロトコルベースのリモートプロセス実行システムである.背景から書くと,XCPUの前身には,BProcという,クラスタをシングルシステムイメージに見せかけるシステムが存在した.BProc(クラスタ)はマスタノードとスレーブノードという二種類のノードから構成される.マスタノードはユーザがログインして,プログラムを実行したり,結果を見るためのもので,スレーブノードで実際にプログラムが実行される.スレーブノードで実行されるプロセスはプロセスマイグレーションを使って,マスタノードから転送される.例

    XCPU - Plan9日記
  • ホワット・ア・ワンダフル・ワールド 質問です.C 言語はだいたいマスターしたつもりです.次はどんな言語を学べば良いでしょうか ? できれば C 言語に近く,かつ近代的な機能も加わっ��

    凡庸な回答 : やはり C++Java でしょうか ? ([どうでもいい] 0 ポイント) 普通の回答 : AWK か Perl をお勧めします.C 風シンタックスで,C では面倒な仕事が簡単に片付けられるようになりますよ ([参考になる] 10 ポイント) 先進的な回答 : C 言語にこだわらず,思考の幅を拡げるためにも,なるべくいろいろな言語をためした方が良いですよ.今なら ML か Haskell をお勧めします.日語のも出ましたし ([参考になる] 15 ポイント) 模範回答 : Alef か limbo をお勧めします.ついでに OS も,Linux とか BSD とか Windows みたいな古くてつまんないのは捨てて,plan9 か Inferno にしましょう ( [素晴らしい回答] -100 ポイント) Plan9 / Alef ってのは,UNIX / C を作

  • Plan9を題材にしたOSの教科書 - Plan9日記

    Francisco J Ballesteros氏によるテキストのドラフトが公開された. Introduction to Operating Systems Abstractions Using Plan 9 from Bell Labs まだ,ぱらぱらとしか目を通していないが,400ページ近くの労作だ.目次はこんな感じで,一通りの内容は網羅しているようだ.すばらしい. Getting started Programs and Processes Files Parent and Child Communicating Processes Network communication Resources, Files, and Names Using the Shell More tools Concurrent programming Threads and Channels User In

    Plan9を題材にしたOSの教科書 - Plan9日記
    yugui
    yugui 2006/09/01
  • コマンドラインヒストリ - Plan9日記

    rcを使っていて,戸惑うのがコマンドラインヒストリがないこと. 正確にはヒストリがないのではなく,シェルの機能ではなく,ウィンドウシステム(rio)の機能であるという点が,UNIXと違う.(カレント)ウィンドウに表示された内容は/dev/textに残っているから,これからgrepせよというのが,Plan9流の考えだ./dev/textはrioが提供する(デバイス)ファイルである.ちなみにacmeの場合は,/mnt/acme/acme/bodyになる(末尾のスクリプトでは,/dev/textにbindしている). スクリプトを書くとこんな感じ.先人に倣って " という名前のスクリプトにしておく." を実行すると最後に実行された5つのコマンドが表示され," mk と実行すると,mk から始まるコマンド履歴が表示される.PROMPT変数は各自の環境に合わせる必要がある. #!/bin/rc rf

    コマンドラインヒストリ - Plan9日記
    yugui
    yugui 2006/07/09
    Plan9の哲学
  • fossil/venti - Plan9日記

    ちょっと前に飲んでいて,ツリー型のファイルシステムは限界だとか,履歴管理ファイルシステムが欲しいという話題で盛り上がっていた. Plan9では,ずっとWORMベースのファイルサーバ(fs)と簡易ファイルサーバ(kfs)が使われてきたが,4th editionからfossil,ventiと呼ばれる新しいファイルサーバ,ブロックストレージサーバが追加された.fossilはfsとkfsを代替するというふれこみだった.fossilは「化石」って意味で,スナップショットが取れるファイルサーバ.ventiだけど,スタバではgrandeより大きいサイズをventiと呼ぶ(日のスタバにはないと思うけど). ventiはUNIXのブロックデバイスドライバに相当すると考えればいいと思うが,特徴的なのはブロック番号がブロックの内容のハッシュ値(SHA-1)になっている点だ.つまり,ハッシュ値が同じブロックは,

    fossil/venti - Plan9日記
  • Text is the universal language - Plan9日記

    UNIXのコマンドはテキストを入力として,テキストを出力する.一つの単純なことを実現するコマンドをパイプでつなげて,より複雑な処理を行なう.Plan9はこの思想を引き継いでいる.以前見たように/dev/mouseをreadして得られるのもテキストだし,exitに相当するexits(2)は引数はintではなく,char *だ.これは分散OSで,ヘテロなアーキテクチャを前提にした場合,テキストは型がなく,扱いが楽だからだろう. あるLisper曰く,UNIXの嫌いなところはすべてテキストなところだ.いつもパージングばっかりやっている.S式だったらどんなに楽なことだろう.

    Text is the universal language - Plan9日記
  • C言語の拡張 - Plan9日記

    Linuxカーネルもgcc拡張を多用しているが,Ken Thompson氏が書いたPlan9コンパイラ(通称Ken C?)も,ANSI Cから拡張がなされている.それらは基的にC99なんだけど,(C99前に実装されたってのもあるんだろうけど)微妙に文法が違っているので,注意が必要である. 例えば,こんな風に変数を列挙して構造体に代入できたり, rio/wind.c 305: m = (Mousestate){w->mc.Mouse, w->mouse.counter};これはC99では,複合リテラル(Compound Literal)と呼ばれるようだ. 次はマウスのメニュで使われる文字列を定義している部分だけど,配列の要素の前に[...]という表記があるが,これは配列のインデックスの指定に使われる. rio/rio.c 58: enum 59: { 60: Cut, 61: Paste,

    C言語の拡張 - Plan9日記
    yugui
    yugui 2006/06/14
  • pipe(2),#|,#s - Plan9日記

    pipe(2)と#|(パイプデバイス)を簡単に比較すると, pipe(2): UNIX同様,親子プロセス間で通信できるシステムコール. #|: UNIXの名前付きパイプに相当し,ファイルにマッピングされる.mkfifoのようなシステムコールではなく,デバイスドライバとして提供され,名前空間を共有するプロセス間で通信できる.POSIXのパイプは単方向であるが,Plan9のパイプは双方向である. パイプデバイスは, bind #| dirという使い方になり,成功するとdir/dataとdir/data1というファイルが作られる.dataとdata1はペアになっていて,dataにデータを書き込むとdata1から読み出すことができ,同様にdata1に書き込んだデータをdataから読み出すことができる.前述のcexecpipe関数でオープンしていたのは,まさにこのdataとdata1である. この考

    pipe(2),#|,#s - Plan9日記
    yugui
    yugui 2006/06/14
  • srvデバイス - Plan9日記

    また,日が開いてしまった.なかなか毎日更新するのは難しいなぁ. UNIXで名前付きパイプ(またの名をFIFOスペシャルファイル)を作る場合は,専用のライブラリ関数mkfifo(3)を使う必要があるが,Plan9では,srvデバイス(#s)を使って実現できる.man srv(3)の例を次に引用する. int fd, p[2]; char buf[32]; pipe(p); fd = create("/srv/namedpipe", OWRITE, 0666); fprint(fd, "%d", p[0]); close(fd); close(p[0]); fprint(p[1], "hello");パイプを生成し,入力側のファイル記述子を/srv/namedpipeに書き込んでいる.これで,/srv/namedpipeへの読書きが,このパイプを介してやりとりできる.例えば,あるプロセスが/s

    srvデバイス - Plan9日記
    yugui
    yugui 2006/06/14
  • initプロセス (ユーザコンテキスト) - Plan9日記

    initプロセスのユーザコンテキストは_main関数から始まる.中身はstartbootを呼んでいるだけ. pc/init9.c 1: extern void startboot(char*, char**); 2: 3: void 4: _main(char *argv0) 5: { 6: startboot(argv0, &argv0); 7: }initcodeは標準入出力をopenし,コンソール,サーバ,環境変数デバイスを/dev,/srv,/envにbindして,最後に/boot/bootをexecする.詳細はboot(8)やboot/boot.cを参照して欲しいが,bootはルートファイルサーバ(ここではPlan9的なファイルサーバではなく,一般的な意味でのファイルサーバを指す)をmountし,/$objtype/initをexecする.ブート時に"root is from(.

    initプロセス (ユーザコンテキスト) - Plan9日記
    yugui
    yugui 2006/06/14
  • ksetenv (環境変数もファイル) - Plan9日記

    環境変数の設定はksetenv関数で行なっている.環境変数は名前と値の組だから,単純にハッシュでも作っているのかなと思ってしまうが,Plan9では,環境変数もファイルとして表わされることを思い出そう. 環境変数cputypeの場合は,#e/cputypeというファイル名のチャネルを生成し,"386"をファイルに書き込んでいる.これからわかるようにデバイスドライバは"#デバイス名/"から始まるファイルツリーとして,リソースをファイルに対応付ける.envデバイスの場合は,フラットなツリーになるけど.そして,"bind #e /env"と実行すると,#e/cputypeは/env/cputypeという別名を持つことになる. port/devenv.c 384: void 385: ksetenv(char *ename, char *eval, int conf) 386: { 387: Cha

    ksetenv (環境変数もファイル) - Plan9日記
    yugui
    yugui 2006/06/14
  • namec〜名前からチャネルを取得する - Plan9日記

    今まで何度か出てきたが,追求を避けてきたnamec関数を見ていこう.と言ってもnamecは350行ほどの大きな関数なので,まずはenvデバイスを例にカーネルデバイスの場合からはじめよう. カーネルデバイスのファイル名は#から始まる.envデバイスの場合は#eだ.そして,devtab経由でattach関数を呼び出し,チャネルを取得している.attach関数はbindmount関数にも出現していた.attachすることでファイルツリーが連結され,プロセスからアクセスできるようになる. port/chan.c 1288: Chan* 1289: namec(char *aname, int amode, int omode, ulong perm) 1290: { 1308: name = aname; 1316: switch(name[0]){ 1322: case '#': 1350: t

    namec〜名前からチャネルを取得する - Plan9日記
    yugui
    yugui 2006/06/14
  • マウス - Plan9日記

    マウスも当然ファイルとして抽象化されている.UNIXなら/dev/mouse*とか,/dev/mse*に相当する.mouseをcatすれば,ポインタの状態を得ることができる.ここまでは一緒だ.これをウィンドウシステムがどのようにプロセス(もしくはプログラマ)に見せるか,という点はX Window Systemとrio(Plan9のウィンドウシステム)の思想の違いが反映されていて面白い.GUI環境では,同時に複数のウィンドウを開くことができるが,(単純に考えて)ウィンドウごとにプロセスが走っているので,複数のプロセスから一つのマウスというデバイスを見せるために,デバイスを多重化する必要がある. Xなどの一般的なウィンドウシステムは何らかのイベント機構を用意して,ウィンドウ上でマウスポインタが操作されたら,該当するウィンドウのプロセスにイベントのメッセージを投げるようになっている. rioは,

    マウス - Plan9日記
    yugui
    yugui 2006/06/14
  • rioウィンドウシステム - Plan9日記

    rioはPlan9のウィンドウシステムである.rioはマウスを多重化して,プロセスごとに/dev/mouseが存在しているように見せかけると書いた.これはマウスに限らず,コンソールやスクリーンに対しても同じことが言える. nsコマンドでrioが起動しているときの名前空間を見てみると, term% ns | grep rio mount '#s/rio.oraccha.23' /mnt/wsys N142,20,140,610,450 mount -b '#s/rio.oraccha.23' /dev#sはsrvデバイスで,サービス用の通信チャネルを提供する.ちなみに,rio.oraccha.23はrio.$user.$pidである.このsrvデバイス経由で/mnt/wsysと/devに「何か」をmountしていることがわかる.「何か」というのはrioが提供するマウスなり,スクリーンといった

    rioウィンドウシステム - Plan9日記
    yugui
    yugui 2006/06/14
  • 1