画面を飛ばす

Xのように画面をリモートに飛ばせるようです。

cpuサーバーにログインして、ローカルのwmを
指定してサーバー側のGUIを起動するようです。

※前エントリーのcpuサーバーへの接続の設定済みとします

%mount {wmexport} /mnt/wm
%cpu tcp!サーバー
; wmimport -w /n/client/mnt/wm wm/wm &

→ ウィンドウが開き、その中でwmが動く。

手前の赤枠のウィンドウ：リモートのGUIを表示させた入れ子のwm(unameがlinux)
左上のシェル:cpuサーバーに接続したシェル。(unameがlinux)
左下のシェル:ローカルのシェル。(unameがdarwin)

※専用アプリがあるようです。wm/dmwm、wm/dmviewを使うらしい。
wmview,wmdmを使う方法はあらかじめサーバー／クライアントでwmが
立ち上がることを前提としているような。

Infernoのサーバーの機能について

Infernoのサーバー機能についてちょっと解って来ました。
Plan9のサーバーは
- CPUサーバー
- 認証サーバー
- ファイルサーバー
にわかれるそうです。
どうやらInfernoもそういう分け方という理解で良さそう。

なお、それぞれのサーバー機能で、サービス名のニーモニック(styxとか、ポート番号を文字列で表現する)とか、ネットワークアクセスをする場合は、あらかじめ
ndb/cs
を実行しておく。

・認証サーバー
認証サーバーのプログラムはsvc/auth。
アカウント情報はauth/changeloginで追加する。

例えば、ユーザー／パスワードを追加するには、
auth/changelogin [ユーザー]
と実行する。

また、auth/createsignerkeyで鍵の生成も必要。
auth/createsignerkey [ユーザー]

認証サーバーを使う場合は、getauthinfoで
認証を行う。

例えば、後述のCPUサーバーの機能を使う場合は、
CPUサーバー、クライアントそれぞれでgetauthinfoを実行する。

・CPUサーバー
サービス名はrstyx。
サーバー側では、getauthinfoを実行するか、svc/rstyxを
実行するとサービスが立ち上がるんじゃなかろうか(自信無い)。
getauthinfo default
signer: 認証サーバー(cpuサーバーと同じ所で認証サーバーを動かすときはlocalhost)
user: ユーザー

保存しますか？にYESと答えると、認証情報が保存される。
再起動後はsvc/net or svc/rstyxの起動だけでよい。

クライアントからはまず認証。
getauthinfo tcp!接続先アドレス
signer: 認証サーバー
user: ユーザー

つぎに、接続コマンド
cpu tcp![CPUサーバー]
とすると、サーバーにログインし、
プロンプトが表示される。
抜けるときはexit。

ほかに、クライアントからはrcmdというのもつかえそう。
こちらはおそらくコマンドの単品実行でしょう。

・ファイルサーバー

ファイルサーバー側ではgetauthinfoを行う。
やり方はCPUサーバーと同じ。
getauthinfoの結果ファイルサーバーが立ち上がるようだ。
save file = yes としたときだけかな？

サーバー立ち上げはsvc/styxで。
または、細かくオプションを選ぶ場合はlisten。
認証(引数にキーを選ぶ)、エクスポートするディレクトリを選べるようだ。

クライアントからはgetauthinfoで認証し(CPUサーバーと同じ)
mountする。
mountは、こんな感じで。
mount tcp![ファイルサーバー] /n/remote
でOK。

※マウント後のファイルの使い方はいろいろ面白いことがありそう。
　例えば、Xみたいに画面を飛ばすのが面白かった。

※svc/net というサーバーコマンドもあるけど、これは
CPUサーバーとファイルサーバー両方まとめて立ち上げるように
思われる。

Inferno-kirkwoodのビルド

Linux環境を壊して、その復旧をしたりとのろのろやっていて
時間がかかってしまいましたが、
先日話題にしたInferno-kirkwood(sheevaplugで動かすInferno)をビルドしてみました。

結局ビルドできた環境はi386上のLinuxのみ。
arm上のLinux、i386上のOSXではいずれも失敗。

以下試したビルド方法。
Infernoのディレクトリは既にある物とする。

os/にinferno-kirkwoodのtrunkを持ってくる。
os/kirkwoodというディレクトリ名にしておく。

os/kirkwoodにsheevainit.bというファイルがあるので、
このファイルをinit/にコピー。

os/Linux/386/binにパスを通す。
まだやっていなかったらmakemk.shを実行。
あ、そのまえにmkconfigの編集が要るかも。
SYSTARGをLinuxに、SYSARCHを386にしておく。

os/kirkwood/mkuimageというディレクトリがあるので、
ここで、mk all;mk install実行。
これは、生成するバイナリをubootで使用できる形式に変換する物。

続いて、os/kirkwood/でmk allを実行。
/usr/以下の○○というファイルが無い、とか言われたら、
空のファイル/ディレクトリで良いので作って再トライ。

すると、uisheeva.gzというファイルができた！
サイズは700kbyte程。

実機で動かしたいけど、動かした後何かしたい訳でもないのでまあいいや。

Acheron Limbo Compiler

Limbo コンパイラーとその実行環境をPOSIXに移植したプロジェクトがあるそうです。

Acheron Limbo Compiler

もしこれが普通に使えそうなら、普段からLimboがいかせるかもしれない。


コンパイルしてみようと思ったが、ごにょごにょしているうちに、
Linuxマシンをおかしくしてしまった。
やる気を失ったので後日・・

なお、ソースはアーカイブになっていないようなので、CVSで持ってくる必要がありそう。
また、コンパイルにはocamlが必要っぽい。



ほかに、Parrotについてもちょっと見てみた。
これは、仮想マシン(レジスタマシン)の実装らしい。
色々な言語に対応しているようだ。
しかし、Limboには対応していないようだ。残念。

Parrot Language

mkuimageがあると便利

Plan9日記にて
inferno-kirkwoodの紹介があった。
InfernoをSheevaplugで動かすプロジェクトらしい。
これは参考になりそう。

で、そこのソースツリーにmkuimageというのがあった。
ubootでブートするためのイメージファイルを作るためのものだと思う。
これ使えないだろうか(OSXで動くといいなぁ)。

それはともかく、このプロジェクトはBeagle Boardの
ネイティブポートの参考になるはずなので見てみることにする。

Sheevaplugもちょっと気になっているが、たぶん買わないと思う。

BeagleboardのLinux emuでUIが動いた

Beagleboard上のLinux上のInferno emuでGUIが動きました。

スタンドアロンではなく、他のマシンのXserverに画面を飛ばしています。

やったこと

・ubuntu on beagleboardの環境整備

apt-getにてxorg, xorg-dev, gcc, mercurialを持ってくる。

・Infernoのビルド

google codeのtrunkをmercurialで持ってきて、ごにょごにょとビルド。

・Xserverの用意。

今回はWinXP上のcygwinのXserverを使ってみた(図)。
いい感じでwm/wmが表示された。

charonを立ち上げようとしたら固まった。まだ完全ではないらしい。

ちなみに、ネットワーク経路はかなりひねくれていて、

beagleboard -(usb)- MAC -(wlan)- hub -(ether)- Win

といった感じ。OSもinferno,linux,osx,win、経路はUSB, wlan, Ethernet、
アーキテクチャもarm, i386と、ふんだんにまたがっています。
MACはネットワークブリッジとシリアルコンソールとして機能している。

※Linuxと対向だったらもっと素直にいけたかも。

なお、スタンドアロンも試みたのですが、startx自体は実行でき、xtermも立ち上がったっぽいのですが、USBキーボードをさしたらXが落ちたっぽい。
引き続き調査予定。

InfernoのHTTPでCGIを書く

InfernoのHTTPでCGIを作成する方法が分かりました。

・HTTPサーバーの起動

svc/httpd/httpd

オプションは
-D デバッグログを出す
-p ポート

・まずは普通のウェブページの表示方法

/services/httpd/rootというディレクトリの下に
htmlソースを置くとアクセスできる。
index.htmlというファイルを置くと、

http://host/index.htmlまたはhttp://host/ でアクセス可能。

サブディレクトリを作ってもOK。

・CGIのサンプル

CGIはhttp://host/magic というパスでアクセスする。
まずはhttp://host/magic/echo
とアクセスしてみる。
すると、なにやら情報が表示される。
これはファイルシステム上の/dis/svc/httpd/echo.disに当たる。
LimboでかかれたCGIファイルで、ソースは/appl/svc/httpdの下にecho.bがある。
これを真似して、例えば同じ場所にtest.disを置くと、
http://host/magic/test
でアクセスできる。

詳細はecho.bをみると大体わかるが、
通常のシェルコマンドと書き方がちょっと違う。

覚えきれるものでもないので、雛形にしてしまうのがよいか。

implement test;

include "sys.m";
 sys: Sys;
include "draw.m";

include "bufio.m";
include "cache.m";
include "contents.m";
include "httpd.m";
 Private_info: import Httpd;
include "cgiparse.m";
cgiparse: CgiParse;

test: module {
 init: fn(g: ref Private_info,
  req: Httpd->Request);
};

init(g: ref Private_info,
  req: Httpd->Request)
{
 sys = load Sys Sys->PATH;
 cgiparse = load CgiParse CgiParse->PATH;
 if(cgiparse == nil){
  return;
 }
 cgidata := cgiparse->cgiparse(g, req);
 bufio := g.bufio;
 Iobuf: import bufio;

 # Send header
 g.bout.puts(cgidata.httphd);

 # Send body
 g.bout.puts("<head><title>test</title></head><body>test</body>\r\n");

 g.bout.flush();
}

リクエストデータはcgiparseの結果に格納され、
method, uri, headerなどのメンバーで参照できて便利。
フォームデータはformでアクセス出来るのでこれでCGIが実現できるはず。
これはtag, valのペアのリストになっているのでhd, tlメソッドで
簡単に取り出せる。

(tag, val) = hd cgidata.form;
cgidata.form = tl cgidata.form;

のループでOK。

cgidataに関してはcgiparse.mを見ると良い。
関係ないけどacme(エディタ)でimport "cgiparse.m";の所で右クリックすると
ヘッダファイルにジャンプしてくれるので実に便利。

・その他

認証には対応していないように見える。

情報があんまり無いので、結局ソースコードから追った。
時間かかった〜。