2013年12月30日月曜日

Xenのコンパイルでbits/predefs.hがみつからないと言われたときは

Xen をコンパイルしていると、 tcgbios.c のコンパイル時にエラーが出力される。ビルドに失敗したときのソースが手元になりのでエラーメッセージを掲載できないが、同様の問題で困っている人がいた。 xen-devel の ML に投稿があった。

どうも 、 tcgbios のコンパイルには、32bit 版の libc が必要らしい。Debian の場合、以下のコマンドで 32bit 版の libc をインストールできる。

  • sudo apt-get install libc6-dev-i386
ML への投稿だと、Xen のソースの中に README があって、そこに Xen をビルドするのに必要なパッケージが書かれているので、そこに、 lib-dev-i386 を追加してくれないか?という提案らしい。ただ、この記事を書いた時点では、まだ追加されている様子はない。(tcgbios はなんで libc6 の 32bit 版に依存するんだろう?という疑問はある。)

2013年12月29日日曜日

zshのサブシェル実行がわからない

Software Design 1月号の第1特集第2章で、サブシェルについての解説があった。紙面のコマンド例ではプロンプトが%だったので、zshかなーと思って、サブシェルの解説で示されていたコマンド例と同じことをやってみたら、結果が異なった。結論から言うと、解説にも書いてあったけど、想定してるのはashまたはdashだった。あと、サブシェルの生成の契機がdashとzshだと違った。

紙面だと、dash で
  • $ (sleep 200 | sleep 200) &
したら、サブシェルが生成されていた。
zshで試すと、以下のようになっていた。
なぜ違うのだろうか。ていうか、そもそも、dashだと、パイプで繋いだプロセスがそれぞれ独立したプロセスとして起動されているのに対して、zshは、パイプの前にあるプロセスの子プロセスとしてパイプの後のプロセスが起動されている。

サブシェルを実行してその中でプロセスを二つ起動するのと、サブシェルを起動せずに、子プロセスとして二つ目のコマンドを実行するのだと、後者の方が高速な気がする。ただ、zshは結構大きいので、起動が遅い。なので、無駄にサブシェルを起動しないようにしているのではないかと思う。

実際に、シェルの起動と終了にかかる時間を測定してみた。dashもzshも、起動時に-cオプションでコマンドを渡せるので、*sh -c exitをtimeコマンドで10回測定した平均を計算した。ちなみに、どちらのコマンドもzshから起動している。dashから起動したら、また違う結果になると思う。

  • dash: 0.0026 s
  • bash: 0.0047 s
  • zsh: 0.0062 s
やっぱりdashが速い。

とここまできて、やっとA User's Guide to the Z-Shellの3.2.3項を読んだのだけど、
In zsh, all but the last portion of the `pipeline' thus created is run in different processes.
らしい。つまり、パイプの最右のコマンド以外は新しいプロセスを生成するらしい。で、() で括ったときにどうなるかというと、どうも、ps コマンドで眺めている感じだと、パイプの最右のプロセスが子プロセスとして生成されて、最右以外のプロセスは最右のプロセスの子プロセスとして生成されるっぽい。謎だ。

3.8.3項, 3.8.4項 あたりをちゃんと読まないと。

2013年12月28日土曜日

とりあえずvagrant使ってみた

Linux Mint 15 で vagrant を入れて、作成したVMにログインできるところまで確認した。ちなみに、vagrant は「放浪者」とかそんな意味だった(alc)。vagrant の公式サイトを参考にした。

  • sudo apt-get install vagrant
ログ見てたら一緒にvirtualboxも入ってた。vagrantは、virtualboxでVM作成するところを自動でやってくれる。
  • vagrant init precise32 http://files.vagrantup.com/precise32.box
vagrant の初期化。カレントディレクトリにVagrantfileを作成する。このファイルはrubyで書かれていて、第一引数は、生成するVMのインスタンス名を指定し、第二引数は、ユーザのシステムに.boxなファイルが無いときに取得しに行くURLを指している。ちなみに、このURLをブラウザに突っ込んだら、website-unavailable.com に飛ばされた。vagrant init 自体は、設定ファイルを生成するだけなので、すぐに終わる。
  • vagrant up
VMを起動する。最初は、VMイメージが手元にないので、vagrant init の第二引数で指定したURLに取りにいってるみたい。二つ目のインスタンスを作ろうとしたら、ダウンロードは起こらなかったけど、Thinkpad X220i (Core i3-2310M@2.10 GHz, 4GB RAM, SSD) な環境で34秒かかった。結構遅い。この処理の内訳も気になる。VMの起動とゲストOSの起動処理の比率で、この34秒が遅いのか否か分かれる。vagrant up したら、/usr/lib/virtualbox/VBoxHeadless とかいうプロセスが起動してた。
  • vagrant ssh
起動したVMにsshでログインできる。パスワードとかはかかってない。あと、コマンドのヒストリを見ると、update-locale とか locale-gen とかしてた。ちなみに、uname -aしたら、Ubuntu 32-bit で Linux 3.2.0-23-generic-pae だった。
  • vagrant suspend
vagrant suspend でVMを停止できる。4.557 秒かかった。
  • vagrant resume
vagrant suspend したVMを再開できる。19秒かかった。ちなみに、vagrant up でも再開できる。
  • vagrant status
vagrant で作成したVMの状態を確認できる。また、VM名を指定することで、各VMごとの状態を確認できるらしい。今回は、一つしかインスタンスを起動していなかったためか、「A multi-vm environment is required for name specification to this command.」と怒られた。
  • vagrant halt
vagrant suspend はサスペンドなので、状態を保持して停止させるけど、vagrant halt は、シャットダウンするみたい。
  • vagrant destroy
停止させる。所謂強制終了と捉えれば良いのか?

とりあえず、ps -ef してみたら、以下のプロセスが起動してた。
  1. /usr/lib/virtualbox/VBoxXPCOMIPCD
  2. /usr/lib/virtualbox/VBoxSVC
  3. /usr/lib/virtualbox/VBoxHeadless
最初のはIPCだから、vagrantコマンドでvirtualboxを制御するためにコマンドを送るインタフェースかな?VBoxSVCは、ここを見ると、SMF Service Wrapperとのこと。書いてあることを素直に解釈すると、「非特権ユーザの所有するvirtualboxインスタンスをSolarisのSMFサービスとして制御する。」とか、「VBoxHeadless VMを起動した後にSMFサービスとしてresumeして、VMへのシリアルコンソールヘ接続する。」とのこと。色々書いてあるけど、要は、virtualboxのインスタンスの管理を便利にするためのものらしい。引数には、「--auto-shutdown」が指定されている。VBoxHeadlessは、man vboxheadlessを読むと、virtualboxのVMを起動したり、起動したVMの画面をキャプチャできるらしい。とにかく、vagrantでは、VMの起動にvboxheadlessを利用している。引数は色々指定されている。--comment でVMのインタンス名を指定しているようだ。--startvmも渡されているようなので、やはり、vboxheadlessでVMを起動している。また、--vrde config も渡されている。これは、よくわからない。

ホスト側から見た環境は、大体、これくらい。次にゲストから見てみる。topを実行すると、「Mem: 378000k total」と表示されるので、378 MBメモリが割り当てられているようだ。cat /proc/cpuinfo すると、processor: 0 の状態しか表示されないので、1コアしか割り当てられていない。gccやmakeは最初から入っているみたい。このあたりのスペックに関しては、vagrant init したときに指定したURLで配布されているイメージの仕様だろうから、どこかに書いてあるだろう。

ざっと見るとこんな感じだった。vagrant -h すると、以下のようなコマンドが利用できるらしい。
  1. box
  2. destroy
  3. gem
  4. halt
  5. init
  6. package
  7. provision
  8. reload
  9. resume
  10. ssh
  11. ssh-config
  12. status
  13. suspend
  14. up
今回書いていない、package, provision, reload あたりがとても気になる。vagrant gem は、vagrantのプラグインをgemを使ってインストールするコマンドらしい。どのコマンドも、vagrant [command name] -h で使い方が表示される。ただし、-h オプションで参照できる情報が異様に少ないので、あまり参考にはならない。

今後は、今回書かなかった(試していないので書けなかった)コマンドや設定ファイルの中身を見ていきたい。

追記(2013/12/29 00:57):SMFはService Management Facility の略らしい。ここに書いてあった。

2013年12月26日木曜日

xen-unstable で seabios 関連のコンパイルエラー

既知のバグに引っかかった.xen-unstable をコンパイルする際に,seabios 関係でエラーが出た.既知のバグらしく,Xen Wiki を見ると,英語以外の言語を利用している環境だと発生するらしい.確かに,日本語環境をインストールしたマシンに Xen をインストールしたのは,初めてだった.以下のように LC_ALL 環境変数を変更して,英語にすることで対処できた.
export LC_ALL=en_US.UTF-8
追記(2013/12/26 17:18):対処できてなかった.いや,そこの問題は突破できたみたいだけど,connection reset by peer とか言われる.困った.

2013年12月19日木曜日

Xenをmake cleanしたときにErrorが出る件

Xen-devel の ML で報告されている([Xen-devel] Make clean failure with qemu)けど、xen/ で make clean するとError が出る。

問題がありそうな xen/tools ディレクトリに移動して make clean したら解決した。原因は何だろ。


2013年12月11日水曜日

Disassemble Linux kernel

Decompress

/boot/vmlinuz-XXX なカーネルイメージは,圧縮されている.通常,disassemble するには objdump を使う.しかし,圧縮されているので,そのままのカーネルイメージには objdump は使えない.そこで,始めに,圧縮されているカーネルイメージを展開する.展開ということで,手元にあるカーネルイメージの圧縮形式はbzip2なので,bunzip2で展開しようとしたけど,無理だった.file コマンドでカーネルイメージを調べると,Linux kernel x86 boot executable bzImage とのこと.通常のbzip2ではなかった.さらに調べると,なんと,最近のLinuxには,vmlinuzをvmlinuxに展開するためのscriptが同梱されているとのこと.遠回りをした結果,ソースのレポジトリに戻ってきた.linux/scripts/extract-vmlinux なるスクリプトがあるので,これを利用する.

Disassemble

既に書いたように,vmlinux形式への展開は完了した.vmlinuxはELF形式の実行ファイルなので,objdumpが使える.ただし,シンボル情報はstripされているので,シンボル情報が欲しい場合は,カーネルのビルドオプションを指定する必要がある.多分できると思う.以下のコマンドでvmlinuxをdisassembleする.