Zynq 事始め1

[前回](/2013/12/ise-vivado-on-ubuntu.html)、ISE/Vivado 等のツール類のセットアップは済ませました。 では何から始めましょうか。 例えば、Zynq の評価ボードを渡され、「じゃ、立ち上げよろしく！」と言われたとしましょう。 （私が言われたみたいに。。） 膨大な資料を前に途方にくれてしまうかもしれません。 似たような状況にある人の手助けになるかどうかわかりませんが、私のたどったステップを記録しておこうと思う。 進めるには、何らかの Zynq ボードが必要となります。 私は ZC706 というボードを使っていますが、他のボードでも似たような感じだと思います。 ### まずはツールに慣れる Zynq を手にとっているということは FPGA ぐらいは経験があるという人が多いと思います。 ISE は使ったことはあるが、Vivado は初めてという人もいるかもしれませんが、 今後のことを考えれば Vivado を使いこなせた方がよいと思います。 とりあえず、ISE および Vivado で簡単な RTL のプロジェクトを作成し、FPGA を Configuration するところまでやってみます。 すでに知っている人は飛ばしてください。 まずは、 ARM は動かさずに、Zynq を純粋な FPGA として使います。 (Zynq の通常の使い方としては、ARM が最初に起動し、ARM から FPGA を Configuration するのですが、それはもうちょっと先に回します。) #### まずは planAhead でやってみる ISE のインストールディレクトリに `settings64.sh` (または `settings64.csh`) というのがあるので、それを `source` したあと、 $ planAhead で起動。 「Create New Project」→「RTL Project」を選択。 「Add File...」 か 「Create File...」 で RTL (Verilog or VHDL) を追加。 とりあえず練習ですので、プッシュボタンを押すと LED が点灯するぐらいの RTL でよいです。 ウィザードの最後で Parts で Zynqチップ名 (xc7z0xx) か評価ボード名を選ぶ。 制約ファイルは自分でいちいち書くのは面倒ですが、大抵はすでに用意してくれている。 自分の場合は、 ZC706 ボードなので、Xilinx のサイトから `zc706-ucf-xdc-rdf0207-rev1-0.zip` というのをダウンロード。 RTL と制約ファイル(UCF)を追加できたら、Synthesis, Implement, Generate Bitstream と進む。 PC とボードの JTAG ポートをつなぐ。 ZC706 の場合は、ボード上に JTAG <-> USB 変換チップが載っているので、USBケーブルでつなぐだけです。 iMPACT を起動すると、「zynq7000_arm_xxx」(=ARM) というのと「xc7z0xx」(=FPGA) というが見えるはず。 2つ見えるのは、Zynq のパッケージ内で ARM コアと FPGA が JTAGデイジーチェーンで繋がっているためです。 FPGA の方を選んで、bit ファイルをダウンロードすると、うまくいくはず。 LED が光ることを確認して下さい。 #### Vivado でもやってみる Vivado のインストールディレクトリに `settings64.sh` (または `settings64.csh`) というのがあるので、それを `source` したあと、 $ vivado で起動。 planAhead と操作手順はほぼ同じですが、制約ファイルが従来のUCF ではなくて、 XDC というファイルです。 Tcl の文法で書かれている。 Synthesis, Implement, Generate Bitstream と進み、最後は、 iMPACT ではなくて、 「Open Hardware Session」というのを選ぶ。 「Open Hardware Session」→「Open a new hardware target」を選び、 `Server name <host:port>` で PC の IPアドレスを入力する(普通はデフォルトでそうなっているはず)。 ポート番号はそのままでよい。 あとは、「Program device」を選べば、 FPGA を Configuration できる。 ちなみに、「Launch iMPACT」というのも選べますが、Vivado 自体は iMPACT を含んでいませんので、 iMPACT を使いたいならば、ISE もインストールし、 `impact` が PATH に含まれていないといけません。 「Open Hardware Session」 というのは、ISE の時の iMPACT と ChipScope の置き換えで、たぶんこっちの方が便利だと思います。 サーバー＆クライアントで使用できます。 このやり方は[後日](/2014/01/vivado-fpga.html)紹介します。 ### もうちょっと RTL を足してみる 上記ができたら、クロックを入れて、LED 点滅とかもやってみます。 クロックラインを BUFG に通す、タイミング制約の追加とかが必要です。 特に Vivado が初めての場合は、 XDC でのタイミング制約の書き方を確認しておきます。 「Project Manager」 → 「Templates」とたどれば、書き方がわかるので、コピペでいけますが。

ISE & Vivado 設定 on Ubuntu

前回記事 [Zynq 入門中](/2013/12/zynq.html) の続きです。 ISE と Vivado を Ubuntu にインストールします。 前回も述べたように、Ubuntu はサポート外なので、そのままでは動かない部分があります。 バージョンによって若干の差があるかもしれないので、ここでは以下のバージョンとします。 - Vivado 2013.2 - ISE 14.6 - Ubuntu 2013.04 64bit ### Vivado のセットアップ #### インストール Xilinx のページから tar をダウンロードして、以下を実行。 $ Xilinx_Vivado_SDK_2013.2_0616_1.tar $ cd Xilinx_Vivado_SDK_2013.2_0616_1 $ sudo ./xsetup 途中のダイアログで Cable Driver をインストールする選択肢があるが、選んでも多分うまくいかないので、 $ cd /opt/Xilinx/Vivado/2013.2/data/xicom/cable_drivers/lin64/digilent$ $ sudo ./install_digilent.sh で直接インストール。 #### 文字化け(豆腐)の修正 planAHEAD は文字化けしないのだが、 Vivado はステータスバーの表示が豆腐になってしまう。 修正の仕方がわからないが、とりあえず日本語である必要はないので、メニューから Tools -> Options... -> General -> Language and Tooltips とたどり Japanese から English へ変更。 #### Documentation のLink が開かない場合の対処方法 IP などの Documentation を開こうとすると、 /opt/Xilinx/Vivado/2013.2/ids_lite/ISE/lib/lin64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/firefox/libxul.so) のようなエラーが端末に出て開かない。 Vivado から起動された firefox がライブラリ検索で `/opt/Xilinx/Vivado/2013.2/ids_lite/ISE/lib/lib64/` 以下を見に行ってしまって、 しかも Ubuntu に元々インストールされているものより古いのが原因のようだ。 以下のように Vivado 添付のライブラリを退避し、`/usr/lib` 以下のものへシンボリックリンクを貼ることで動くようになった。 $ cd /opt/Xilinx/Vivado/2013.2/ids_lite/ISE/lib/lin64 # mv libstdc++.so libstdc++.so.bak # mv libstdc++.so.6 libstdc++.so.6.bak # ln -s libstdc++.so.6 libstdc++.so # ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ### ISE のセットアップ #### インストール Xilinx のページから tar をダウンロードして、以下を実行。 $ tar xf Xilinx_ISE_DS_14.6_P.68d_3.tar $ cd Xilinx_ISE_DS_14.6_P.68d_3 $ sudo ./xsetup #### PlanAhead が起動しない場合の対処方法 PlanAhead が異常終了し、コンソールに以下のようなメッセージが出る。 /opt/Xilinx/14.6/ISE_DS/PlanAhead/bin/rdiArgs.sh: 95 行: 13848 Segmentation fault (コアダンプ) "$RDI_PROG" "$@" 以下のようにして、ISE に付属の libjvm.so を置き換える。 $ sudo apt-get install openjdk-7-jre $ cd /opt/Xilinx/14.6/ISE_DS/PlanAhead/tps/lnx64/jre/lib/amd64/server/ $ sudo mv libjvm.so libjvm.so.bak $ sudo ln -s /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so [ここのページ](http://forums.xilinx.com/t5/Installation-and-Licensing/RHEL5-64-bit-ISE-13-1-PlanAhead-launch-from-w-in-ISE-fails/td-p/148624/page/2) を参考にしました。 #### XilinxNotify のエラーダイアログの対処方法 root 権限でインストールした場合、PlanAhead 起動時に以下のようなエラーダイアログボックスが出る。 A disk write failure occurred. There may be insufficient disk space or you may not have write permisson at the following directory. /opt/Xilinx/14.6/ISE_DS/.xinstall Press Retry to try again, press Cancel to exit XilinxNotfy エラーの原因は、 root にしか書き込み権限のない `/opt/Xilinx/14.6/ISE_DS/.xinstall/` の下に `xilinxnotify.log` というファイルを作ろうとしているため。 インストール時は、root 権限、アプリ実行は 一般ユーザーで行うのが普通なのに、なんでこんな場所にログファイル作っちゃうんだろうね？ クオリティ低いですな。 とりあえず以下のようにして回避。 $ sudo chmod a+w /opt/Xilinx/14.6/ISE_DS/.xinstall #### Xilinx License Configuration Manager からライセンス取得できない場合の対処方法 Connect Now ボタンを押しても、ブラウザが開かずに端末に以下のメッセージが出ている。 /usr/lib/chromium-browser/chromium-browser: /opt/Xilinx/14.6/ISE_DS/common//lib/lin64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/lib/chromium-browser/chromium-browser) 以下のようにして shared object 置き換え。 $ cd /opt/Xilinx/14.6/ISE_DS/common/lib/lin64 # mv libstdc++.so libstdc++.so.bak # mv libstdc++.so.6 libstdc++.so.6.bak # ln -s libstdc++.so.6 libstdc++.so # ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #### Document が開かない場合の対処方法 ドキュメントをブラウザで開こうとするが、GLIBC の互換性の問題で開かない。 上記と同じなので、端末のエラーメッセージを見ながら `libstdc++.so` を置き換える。 ### fpga editor が起動しない場合の対処方法 ### コンソールに以下のようなエラーメッセージが出る。 /opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/_fpga_editor: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory ここでも shared object の問題のようだ。 パッケージ名がわからない場合は `apt-file` で調べられる。 $ apt-file search libXm.so.3 libmotif4: /usr/lib/x86_64-linux-gnu/libXm.so.3 $ sudo apt-get install libmotif4 一歩前進したが、まだ以下のようなエラーメッセージが出る。 /opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/_fpga_editor: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory 以下をインストール。 $ sudo apt-get install libstdc++5 まだ以下のようなエラーメッセージが出る。 Wind/U X-toolkit Error: wuDisplay: Can't open display 環境変数が `DISPLAY=:0.0` になっているのを修正 $ export DISPLAY=:0 まだ以下のエラーメッセージが出る。 Wind/U Error (193): X-Resource: DefaultGUIFontSpec (-*-helvetica-medium-r-normal-*-14-*) does not fully specify a font set for this locale フォントをインストール。 $ sudo apt-get install xfonts-75dip xfonts-100dpi ようやく起動した。 #### ChipScope が起動しないときの対処方法 ChipScope Analyzer が起動せずに /opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/unwrapped/analyzer: 72: /opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/unwrapped/cs_common.sh: XIL_DIRS[0]=/opt/Xilinx/14.6/ISE_DS/ISE/: not found /opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/unwrapped/analyzer: 73: /opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/unwrapped/cs_common.sh: count++: not found /opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/unwrapped/analyzer: 152: /opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/unwrapped/cs_common.sh: Syntax error: Bad for loop variable というエラーメッセージが端末に出る。 これは `cs_common.sh` 中で bash の拡張機能を使っているにも関わらず、shebang が `#/bin/sh` になっているから。 Xilinx がサポートしている RedHat系ディストリビューションでは `/bin/sh` が `/bin/bash` へのシンボリックリンクになっているために、__たまたま__ 動いてしまう。 Ubuntu では動かない。(Ubuntu では `/bin/sh` は `/bin/dash` へのシンボリックリンクになっている。) そこで、 `/opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/unwrapped/cs_common.sh` を開き、一行目を `#!/bin/bash` に書き換えるが、やはり動かない。。 よく見ると、 analyzer から `cs_common.sh` を source している。 なので `/opt/Xilinx/14.6/ISE_DS/ISE/bin/lin64/unwrapped/analizer` を開き、一行目を `#!/bin/bash` に書き換えると、、ChipScope が起動するようになりました。 #### Export Hardware for SDK が失敗する場合の対処方法 ダイアログボックスが開き、 ERROR: [Common 17-49] Internal Data Exception: xps application failed! というメッセージが出る。`gmake` がいるようだ。 ln -s /usr/bin/make /usr/local/bin/gmake ### ISE と Vivado 共通のセッティング #### Xilinx SDK で arm-xilinx-eabi-gcc が not found の場合の対処方法 xsdk を起動して、プロジェクトをビルドするときに /bin/sh: 1: arm-xilinx-eabi-gcc: not found のエラーがでる場合がある。 `settings64.sh` を source すれば、 `arm-xilinx-eabi-gcc` への PATH も通るはず。 端末上から `arm-xilinx-eabi-gcc` が見えているのに相変わらず動かない場合。 $ which arm-xilinx-eabi-gcc /opt/Xilinx/14.6/ISE_DS/EDK/gnu/arm/lin/bin/arm-xilinx-eabi-gcc $ arm-xilinx-eabi-gcc --version arm-xilinx-eabi-gcc: No such file or directory 原因は、`arm-xilinx-eabi-gcc` が 32bit ホスト用であるため。以下を実行してみればわかる。 $ file `which arm-xilinx-eabi-gcc` /opt/Xilinx/14.6/ISE_DS/EDK/gnu/arm/lin/bin/arm-xilinx-eabi-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped これを 64bit ホストで動かすには 32bit 用のライブラリが必要なので、以下のようにインストールする。 $ sudo apt-get install ia32-libs もはや 32bit ホストで FPGAやるのは難があるのだから、 64bit ネイティブでツールをそろえて欲しいところですが。。 #### ノードロックライセンスを全ユーザーから使えるようにする 通常はライセンスファイルは ~/.Xilinx に置かれるが、環境変数で変更できるので、 /opt/Xilinx 以下に置き、各ユーザーが export XILINXD_LICENSE_FILE=/opt/Xilinx/Xilinx.lic の環境変数設定。 ### 端末表示関連 Zynq 上の ARM と UART で通信しなくてはならないので、そのセットアップ。 最近のデスクトップPC にはシリアルポートがついてなかったりするのですが、 評価ボード上には USB-UART 変換(CP210X)が載っているので問題なし。 #### USB-UART ドライバ Windows ならば、SiliconLab のページから CP210X のドライバをダウンロードしてくるところですが、 Linux では、Kernel のソースツリーに CP210X のドライバが含まれているので、何もしなくてよい。楽だな。 Ubuntu ならば `CONFIG_USB_SERIAL_CP210X=m` でビルドされているので、ボードと USBケーブルでつなぐだけで勝手にモジュールがロードされるはず。 試しに、ボードとUSBケーブルでつないでみて、 $ lsmod | grep ^cp210x cp210x 17382 0 みたいに表示されれば、ちゃんとロードされている。 ちなみに、ドライバは `/lib/modules/3.*.*-*-generic/kernel/drivers/usb/serial/cp210x.ko` にインストールされている。 モジュールのロードと同時に `/dev/ttyUSB0` が作られているはず。 $ ls -l /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 0 8月 22 11:08 /dev/ttyUSB0 でわかるように、dialout に所属していないとアクセスできないので、以下のようにする。 $ sudo gpasswd -a <user_account> dialout #### ckermit メモ ターミナルソフトは、 Windows なら TeraTerm が有名ですが、Linux なら ckermit がおすすめです。 $ sudo apt-get install ckermit でインストール。 $ kermit で起動。 (/home/masahiro/) C-Kermit>set line /dev/ttyUSB0 (/home/masahiro/) C-Kermit>set carrier-watch off (/home/masahiro/) C-Kermit>set speed 115200 /dev/ttyUSB0, 115200 bps (/home/masahiro/) C-Kermit>connect でつながるが、毎回入力するのが面倒なので `~/.kermrc` に set line /dev/ttyUSB0 set carrier-watch off set speed 115200 connect を書いておきましょう。 閉じるときは `Ctrl-\` のあとに `c`。

Zynq 入門中

### Zynq とは 最近、仕事で Zynq やってます。 Zynq というのは、 Xilinx からリリースされている ARM + FPGA の SoC である。 Xilinx は All Programmable SoC というキャッチフレーズで呼んでたりする。 なお、Altera からは SoC FPGA という同様のものが出ている。 CPU と FPGA を1チップに、というコンセプトは今に始まったことではない。 私の知る限り、 Virtex II のころから PowerPC 内蔵 FPGA はあったし、ソフトコアなら Microblaze もある。 しかしながら、世の中の流れは ARM なわけで、 ARM を採用している時点で裾野は広い。 かくいう私も ARM 以外のアーキはさっぱりわからないので、これは助かる。 しかも SoC としての完成度が高いので、使いこなせればいろいろと応用が効きそうだ。使いこなせればね。。 とりえあず、入門程度に LED を光らせる回路を作って、ARM から制御する簡易プログラムを組むぐらいのことならば、チュートリアル見つつやっていけばなんとかなる。 ただし、最終的には、自作のハードウェアIP を実装して、 Linux のデバイスドライバも書いて、っていうところに行き着くことが多いだろうから、なかなか一筋縄ではいかなさそうだ。 ともかく愚痴だけにならないように、役に立ちそうな内容を書き綴っていけたらと思う。 ### 最初の分かれ道: ISE か Vivado か 現時点では、IDE (統合開発環境)の選択肢が大きく分けて 2つある。 ISE は昔からあるツールで Xilinx の FPGA をやったことのある人にはお馴染みだろう。 一方、Vivado (ビバドと読む) は新しいツールである。 #### ISE で Zynq をやる場合 プロジェクトマネージャーとして 「Project Navigator」か 「PlanAhead」を使うことになる。 「Project Navigator」は内部から「PlanAhead」を呼び出すので、プロジェクト管理自体に「PlanAhead」を使ってしまうのがよいと思う。 「PlanAhead」上で RTL や制約ファイル、ジェネレートしたIPなどの全体の管理を行い、ハードウェア情報のエクスポートも行う。 IP を生成したり、Zynq の設定をいろいろといじくったりするには、 XPS (Xilinx Platform Studio) を使う。 FPGA のコンフィグレーションには iMPACT を使い、回路の解析(ロジアナ)には ChipScope を使う。 配置配線結果を見ようと思ったら、 FPGA Editor が起動する。 お分かりのように、用途ごとにツールが乱立しており、ISE はそんなツールの集合体なのである。 上記はハード屋さんが使いこなすツールで、さらにソフトの開発には XSDK (Xilinx SDK = Eclipse を Xilinx 用に拡張したもの)を使う。 #### Vivado で Zynq をやる場合 Vivado を選択した場合、ハード周りのツールは Vivado 1つに統合される。 ハード開発に Vivado、ソフト開発に XSDK と2つのツールで済んでしまうのはメリットだ。 #### Vivado の長所短所 長所 - PlanAhead, XPS, iMPACT, ChipScope, FPGA Editor など、用途ごとにいろんなツールが起動していたのが、Vivado 1つで済む。 - IP間の接続などを Schematic で設計可能。 XPS では、IP 間のバスや信号をダイアログで選択しながら、接続していく（画像左側）ため、けっこう手間。 Schematic 表示も可能ではあるが、あくまで表示だけであって、Schematic 上で編集したりはできない。 一方、Vivado では回路図を引くような感じで、さくさくとポート間を接続していけるので、楽（画像右側）。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJLHVFUGfdOBGMTE4DZEO31NDBShOgbDFZkVdeFYYWtLkbtTqvNoiLHqJlja-bcpFz-pKHXZx1xi__nOuBOfXIiEl1e3ZQ-iiBOoj-j37Q7oy3aiOMIhT2jibKPLkDoRRWttJt5fN6YJ0/s1600/xps.jpg) [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjbjPRhDjZ7B6G22YuwFrKHnTzh-t39ulvhuXKvmnzuGShbsR49ZlWvuIIsD7O5CR2JV-mmUb3wQnM-IQUfzFogPWOKwknnYha8O2fLCti21zK7jORRpTSYBoiIon6nmmHCknO28O4yNU/s1600/vivado.jpg) - 今後のアップデートが期待できる。 Xilinx の開発の中心はすでに ISE から Vivado へと移っていると思われる。 今後 ISE のメンテを積極的にやっていくつもりはないであろうから、すでに発覚している ISE のバグの修正はあまり期待できない。 (特に、Linux 上で buggy な PlanAhead を使うのに嫌になっている。) - リモートで、FPGA のコンフィグレーションやロジック解析ができる。 - 合成、配置配線が ISE より速い。 短所 - よくも悪くも、新しいツールのため、こなれていない。 使っていた限り、現時点の最新版 (2013.2) でも十分使えると思うが、いくつかバグも目についた。 (Linux 版で、Zynq 設定の GUI インターフェースがバグってる。) ただし、今後のアップデートで、修正が期待できる。 - Vivado に対応していないドキュメントが結構ある チュートリアルなどが、ISE を対象に書かれている。 ある程度は、ISE と Vivado の両方の使い方を理解した上で、 ISE について書かれたドキュメントを頭の中で Vivado に変換しながら、読み進めていくのが良さそうだ。 - ISE に慣れた人にとっては、新たな勉強が必要 ISE との使い方が大きく異なるということはないのだが、ある程度差分があるので、多少の勉強は必要だ。 特に、制約ファイルは ISE で長年使われていた UCF ではなくて、 Vivado では XDC という Tcl ベースの書き方になる。 以上のことから、ツールとしては ISE と Vivado を両方共インストールし、両方のツールの基本的な使い方を理解 （少なくとも ISE を対象にしたドキュメントを読み進められるように）した上で、Vivado をメインに使っていくことにする。 ### Windows か Linux か FPGA も巨大になってきて、64bit OS 上にインストールするのがほぼ必須になってきているが、さて、ツールのインストール先は Windows か Linux か。 Zynq 上で Linux を動かすのならば、ISE/Vivado も Linux 版をインストールするのがよいでしょう。 Linux Kernel のビルドには Linux ホストが必要になるためである。 ハード開発は Windows、ソフト開発は Linux と分かれていると、生成したバイナリをいちいち転送して、結合して、なんてのを繰り返すことになって面倒なのだ。 ハード専任担当者でソフトを触る予定がない人や、Linux を動かす予定がない人は、Windows/Linux は好きに選べばよい。 なお、ツールのライセンスはノードロックが通常(MACアドレスを登録します)と思いますが、3回まではライセンスの移動できます。 Xilinx のページからライセンスファイルを再発行すればOK。 なお、無限に移動させたい場合は、USB - Ethernet 変換を買って、それをドングル代わりに使うのがよいかも。。 いろいろ書きましたが、 Windows は 私の趣味に合わないので、以下 Linux 上に ISE と Vivado をインストールして進めます。 ただし、 Linux 版の ISE/Vivado で正式にサポートされているのは Fedora であって、 Ubuntu はサポート対象外です。 ただし、多少の設定を最初にやれば、 Ubuntu でも十分に使えるようになる。 Ubuntu だけあって、このあたりの情報も検索すればいろいろと出てくるので問題無し。 [次回](/2013/12/ise-vivado-on-ubuntu.html)は、ISE/Vivado を Ubuntu にインストールする際の設定をまとめようと思う。

ELCE 2013 & U-Boot Mini Summit in Edinburgh

先週、Embedded Linux Conference Europe と U-Boot Mini Summit に参加するために、イギリスはエジンバラまで行ってきました。 <br /> ホテル - 会場間の町並み。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirPj1P8i3rIuxPdODUlhZjJwJFKJ6ugt3vUbiRTXBgQO5rs-30szPXSYOxnU4DsS3UlelF4dv87vY2f2N5AVYvAJGsObiy11i7I68bAAKsBqquLm2WBLCHwSF45DhqdB47U_Y6KgAw8xI/s1600/street.jpg) <br /> 23日夜はレセプションイベントがありました。会場のNational Museum of Scotland。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRYu550R-0KFixTu2VojCQJOBXi5s-tQFzYukiCUvOeFtK6EXVhmp6dpBIbiiEhVT15TzVeLQYFMu2NU8MxjESXyPF35RHFcMO56-qMVLegyzLy8VwAyYVE8BLZqknEDwnd_7VNCX5oDw/s1600/nmos.jpg) <br /> レセプションではディナーやカジノを楽しむことができます。自分はルーレットやってました。<br /> 途中までは、ビギナーズラックでかなり勝ちました。最終的に全部なくなりましたが。。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNqiimLiEcp09ugfVIsCDepZxetSK6AC8zqb7RtglVS0neEygw8Dghte6SLwnwKPpYGNJ6ef0YMvNb2yGjhs_zgnxW0Gfdp4CKBIJbwj8L_KUrJqovwvVxyGnz0vDcXZiHN2xLM5-BQw0/s1600/casino.jpg) <br /> ELCE 会場の Edinburgh International Conference Centre。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0ZFnsNxeg3eh4xOLrYsE3EkkTwAW1fhY_WLWTUFP2NHXync90YvJ9-bxCKaNX1uNfgnWd3IiXQLhH0MTuPu2psYD2s8f4ArCfaQ5MWSwela9cjGK5ITqrnbAn9R9yCwDkv0QDLdDMyeI/s1600/eicc.jpg) <br /> 受付や休憩場所のある Strathblane Hall の様子。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0cMFCbFM8dkDPmu1lVAfjveSDkNg4ASr1XQ_yi1IfUwQWcIY8WkXgu6fIAWvk5RAvKq4lxZPMq5ymIiGR24FZdBPVsiK8kLfk-vup-C4mxSBzV7OmTpgiDV0qJKR_RKolouGDN9kUJuQ/s1600/strath.jpg) <br /> Chris Simmonds 氏による Keynote。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY6NYWUZZZ0X72IoFEymIlFrfmfM_J-7d3nTF9eP-qS_QkOph_XTDb4tmoDlQSvWsEyAOUFVj7qxWL4PVL4fk2uSeFv-1tY86sx9nghkiD6Vcxiwbdvjb0FD9O18hAB0-lOULK3D92AgU/s1600/keynote.jpg) <br /> 同会場で開催された U-Boot Mini Summit にも参加。<br /> こちらはこじんまりとした感じ。聴衆は30〜40人くらいだったでしょうか。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTatXYS2Q8QQYvIN0q6zw9092y3hyJjUUrCTzUlA3r1RcgvMVabfsQCmy8ogySyOnx70__TOH3ydUcuitJbW35l9hYxWk3NE4EAx2sOp6lEhK4Oo3-TI2spOO5acyWxTYX3vR5OWP1CHw/s1600/uboot.jpg) <br /> 私が最近投稿していたパッチがスライドで紹介されているところ。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilI5ZAuElXLNObhvqdftwhMRw8AGyRTDHf2skwS7d3HlHTyEyOKuFNdZJcgEkKC25shTSbvXODAxcPXVwoJyLgI23ggZXiB7-GiPh9gFIQiPoXMfVevXZ-0BbhiAv9qeWLefMQMqEOoRc/s1600/uboot2.jpg) <br /> 24日夜は、U-Boot 開発陣で飲みに行きました。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL9tOETkiGiBUFfOw-oKKqq1hni0E6Hr4wsciWyL_y0yKxU_Y9u22TBNZXu-UZgBsiG5o1ewXTJbRGplyJ2BRHBE9V7nnL95b4wdmUajN_Vc7Vfr2CmQ9Xqmc7CI58kX2MhIvSyWJR-9A/s1600/bar.jpg) <br /> Closing Gameの様子。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcR0mL889R_KmIaNb0TVX0gDIg3YYOAmIYCYRR6V5Xch9cAeWzqdpZSlPpKvcDDA-hV-h3zaNJZ8u-RfrK9T1YJAvjwC6Z41YmgKpcuctMNO2wTrfaSy3OUTbMueSwXs_dLYJom30t0bw/s1600/closing.jpg) あるアンケートに対して、答えた人数が多い回答を当てていく。<br /> 3回 Strike すると、回答権が相手チームに渡り、当てるとポイントを Steal できる。<br /> 要するに、昔やってた「関口宏のクイズ100人に聞きました」ですね。 <br /> 勉強にもなり、かつ楽しい一時でした。 普段 ML でやりとりしている人と直接会って話ができたのも良かったです。 来年の開催地はデュッセルドルフ。また行きたいです。

git の Acked-by と Reviewed-by

git log に付けられるタグで Acked-by と Reviewed-by の使い分けがよくわからなかったので、調べてみた。 翻訳が間違っている可能性もあるので、原文は [https://www.kernel.org/doc/Documentation/SubmittingPatches](https://www.kernel.org/doc/Documentation/SubmittingPatches) の 13) と 14) を参照してもらうとして、 ざっくりと、以下のように理解した。 - Signed-off-by: そのパッチのコード開発に関わった人、および そのパッチが投稿からマージに至るまでに経由した人を表す。 - Acked-by: そのパッチの開発に直接関わったわけではないが、 そのパッチをレビューし、パッチを取り込むことに賛成したことを示す。 管理者はパッチをマージする際に "yep, looks good to me" といった類のコメントを Acked-by タグに置き換えることがある。 実際、 Acked-by タグは、そのパッチが影響する分野の管理者によってよく使われる。 Acked-by を発行する際に、そのパッチすべてに対し承認する必要はない。 例えば、そのパッチが複数のサブシステムに影響する場合、 少なくとも自分の管理するサブシステム上で受け入れ可能であれば、Acked-by を付けることができる。 - Cc: そのコミットが変更する分野に関連する人で、まだコメントをしていない人を Cc: タグとして追加する。 Cc: は、タグに示された本人が明示的なアクションを取らなくても、追加されることのある唯一のタグである。 - Reported-by: 自分以外の人が報告した問題を修正する場合に、このタグを追加する。 ただし、報告者に事前に了承を得た上で追加すること。 つまり、このタグが付いているということは、バグが解決するまで、 報告者の協力が期待されるということ。 - Tested-by: タグのついている人によってテストが行われたことを示す。 - Reviewed-by: このパッチがレビューされ、(そのレビュアーの見地内では) パッチを取り込んでも問題ないと判断したことを示す。 そのパッチに興味を持った人は誰でもこのタグを提供することができる。 管理者にとって、このタグはレビューの進行度の目安になる。 特にその分野のエキスパートからの Reviewed-by タグが付いている場合、 そのパッチが取り込まれる可能性が高くなる。 - Suggested-by: このパッチのアイデアが、このタグのついている人のものであることを示す。 ただし、事前に報告者に了承を得た上で追加すること。 つまり、このタグに示された人からの協力が、将来の改変に渡って、期待できることを示す。 で、結局のところ Acked-by と Reviewed-by はどう使い分ければいいのか、依然すっきりしないのだが、 [http://linux-kernel.2935.n7.nabble.com/acked-by-meaning-td551744.html](http://linux-kernel.2935.n7.nabble.com/acked-by-meaning-td551744.html) を読むとはっきり書いてあった。 ポイントは Acked-by は特定分野のメンテナーによって使われることが多いという点。 Acked-by は発行する人（のランク）によって意味が違ってくる。 あるサブシステムのメンテナーが Acked-by を付けた場合、 自分の管理範囲では、問題ない、ということを示していて、 通常の使い方においては Reviewed-by より強い意味を持つ。 逆に、何の管理者にもなっていない人によって付けられた Acked-by は Facebook の「いいね」程度の意味しかない、だそうだ。 その分野で、そこそこの重鎮になってもないのに、 Acked-by を使うと 「てめえにわざわざ Ack される筋合いねーよ、このペーペーが！」 ということになりかねないので、使い方に気を付けることにしよう。

Git tips

たまにしか使わないものなど、忘れがちなものをメモ。 ### リポジトリのトップディレクトリを表示 ### $ git rev-parse --show-toplevel ### bare repository として clone する ### $ git clone --bare <repository> ### bare repository で current branch を変更する ### bare repository は working tree は持たないので、 $ git checkout <branch> fatal: This operation must be run in a work tree のようにはできないので、 $ git symbolic-ref HEAD refs/heads/<branch> とする。 ### リモートネームを追加 ### 例えば、 origin という名前をつける場合 git remote add origin <url> これで、長ったらしい <url> の代わりに `origin` という名前が使える。 ### git push と同時に追跡ブランチ設定する ### git push -u <repository> <branch> のように `-u` オプションをつける ### リモートブランチの削除 ### git push <repository> :<remote_branch>

make が関数を展開するタイミング

GNU make での話。 makefile のコマンド行は単純に、上から1行ずつ順番に実行されるものと思っていた。 例えば、次のような makefile を作成。 all: echo foo > a cat a `echo` コマンドをファイルにリダイレクトし、すぐさま `cat` で読み出すという単純なものです。試しに実行してみます。 $ make echo foo > a cat a foo 予想通りの結果。 では、 makefile をちょっとだけ変えて、 all: echo foo > a echo $(shell cat a) としてみる。同じ結果になると思いきや、、 $ rm -f a $ make cat: a: そのようなファイルやディレクトリはありません echo foo > a echo なんと、動かないではないか！ `echo foo > a` よりも `cat a` が先に実行されてしまっているようです。 この実験結果を見ると、上から1行ずつ関数を展開しつつ実行するのではなく、 すべての関数を展開してしまってからコマンド行を上から順に実行するように見えます。 しかも、関数を展開する順番は、出現順でもないらしい。 例えば、 all: : $(shell touch a1) touch a2 echo $(shell ls a*) という makefile を実行すると $ rm a* $ make : touch a2 echo a1 a1 となった。 `$(shell touch a1)` → `$(shell ls a*)` の順に行われているようです。 一方、 all: : $(shell touch a1) touch a2 echo $(wildcard a*) という makefile を実行すると $ rm a* $ make : touch a2 echo となった。 今度は `$(wildcard a*)` → `$(shell touch a1)` の順に行われたようです。

VirtualBox 自動起動

ホストOSが起動した時に、ゲストOSも自動的に起動して欲しい！そう思ってやってみました。 動作確認は Ubuntu 12.04 LTS および Ubuntu 13.04 で行なっています。 - VirtualBox 本家からダウンロードしてインストールした場合 - Ubuntu 13.04 で apt-get でインストールした場合 - Ubuntu 12.04LTS で apt-get でインストールした場合 の順番に説明します。たぶん、最初のが正式？なやり方。 ### 本家からダウンロードする場合 ### <http://www.virtualbox.org/manual/ch09.html#autostart-linux> に記載があるのですが、VirtualBox 4.2 から autostart に対応しています。 一応、Ubuntu でやってみましたが、同じやり方でほぼすべてのディストリビューションで動くはず。 #### インストール方法 #### <https://www.virtualbox.org/wiki/Downloads> のページに行き、 自分のディストリビューション用のパッケージをダウンロードしてきて、インストールする。 (現時点では VirtualBox 4.2.12 for Linux というのがダウンロードできるようだ。) #### 設定方法 #### $ sudo -i # mkdir -p /etc/vbox/autostart_db # chmod 1777 /etc/vbox/autostart_db # echo "default_policy = allow" > /etc/vbox/autostart.cfg みたいな感じで、データベースディレクトリ `/etc/vbox/autostart_db` およびコンフィグファイル `/etc/vbox/autostart.cfg` を作ります。 名前は必ずしもこの通りでなくてもいいです。 後で `VBOXAUTOSTART_DB` 変数と `VBOXAUTOSTART_CONFIG` 変数にこれらのパスをセットするので。 `/etc/vbox/autostart_db` ディレクトリは一般ユーザーが設定ファイルを作成したり、削除したりするので、全員に書き込み権限を与えます。 ただし、他のユーザーの設定ファイルを勝手に削除できないように、sticky ビットを立てておきます。 `/etc/vbox/autostart.cfg` のコンフィグファイルは # Default policy is to deny starting a VM, the other option is "allow". default_policy = deny # Bob is allowed to start virtual machines but starting them # will be delayed for 10 seconds bob = { allow = true startup_delay = 10 } # Alice is not allowed to start virtual machines, useful to exclude certain users # if the default policy is set to allow. alice = { allow = false } みたいな感じでユーザーごとに設定することもできるが、とりあえず default_policy = allow の1行だけ書いておけば動きます。 次に、 `/etc/vbox/vbox.cfg` (または `/etc/default/virtualbox`) というファイルを作って、データベースディレクトリと設定ファイルへのパスを追加します。 VBOXAUTOSTART_DB=/etc/vbox/autostart_db VBOXAUTOSTART_CONFIG=/etc/vbox/autostart.cfg みたいに追加します。 続いて、ユーザーごとの設定をします。 $ VBoxManage setproperty autostartdbpath /etc/vbox/autostart_db $ VBoxManage modifyvm VM_NAME --autostart-enabled on とします。 (`VM_NAME` の部分は動かしたい仮想マシン名に置きかえてください。) 上記をすると、 `~/VirtualBox VMs/VM_NAME/VM_NAME.vbox` に以下のように Autostart enabled の設定が書き込まれます。 <AttachedDevice passthrough="false" type="DVD" port="0" device="0"/> </StorageController> </StorageControllers> + <Autostart enabled="true" delay="0" autostop="Disabled"/> </Machine> </VirtualBox> さらに `/etc/vbox/autostart_db/` 以下に `USER_NAME.start` というファイルが作られ 中身は `1` が書かれています。 ファイルの中身は、自動起動する仮想マシンの台数を表しています。 もう一台 `--autostart-enabled on` すると `2` になります。 中身が `0` になるとファイル削除されます。 `VM_NAME.vbox` とか `/etc/vbox/autostart_db/` 以下のファイルを直接いじると辻褄が合わなくなるので、理屈を理解しないうちは $ VBoxManage modifyvm VM_NAME --autostart-enabled on とか $ VBoxManage modifyvm VM_NAME --autostart-enabled off とかコマンドで操作するのがよいです。面倒ですけどね。。 ちなみに $ VBoxManage modifyvm VM_NAME --autostop-type acpishutdown として autostop の設定もすることはできますが、現時点では autostop は動かないらしい。。 以上で、設定は完了です。 再起動すると、VirtualBox も自動起動するはず、、、と思ったら起動しない。 ちょっと落とし穴がありました。 `/etc/init.d/vboxautostart-service` の中身を見てみると vboxdrvrunning() { lsmod | grep -q "vboxdrv[^_-]" } のように vboxdrv モジュールがロードされているかどうかを確認するコードがあります。 vboxdrv をロードしているのは `/etc/init.d/vboxdrv` です。 つまり、 `/etc/init.d/vboxdrv` より後に `/etc/init.d/vboxautostart-service` が実行されないといけません。 `/etc/rc2.d/` の下を `ls -l` で見てみると、 S20vboxautostart-service -> ../init.d/vboxautostart-service S20vboxdrv -> ../init.d/vboxdrv となっています。怪しいな。。 そこで `S20vboxdrv` を `S19vboxdrv` にリネームしてみました。 S19vboxdrv -> ../init.d/vboxdrv S20vboxautostart-service -> ../init.d/vboxautostart-service これで再起動すると、、バンザーイ。動きました。 `/etc/init.d/virtualbox` は簡単なシェルスクリプトなので読んでみると、起動時のシーケンスは 1. `/etc/init.d/vboxautostart-service` を実行 2. `/etc/vbox/vbox.cfg` と `/etc/default/virtualbox` 読み込む 3. `/etc/vbox/autostart_db/*.start` を見て、ユーザーを確認 4. ユーザーごとに `/usr/lib/virtualbox/VBoxAutostart` を実行。引数に `/etc/vbox/autostart.cfg` を渡す という感じになっているようです。 ### Ubuntu 13.04 で apt-get でインストールした場合 ### Ubuntu 13.04 で $ sudo apt-get install virtualbox でインストールした場合です。 この場合、VirtualBox4.2.10 がインストールされますが、本家サイトからパッケージをダウンロードしてきた場合と、 etc ファイルの構成がかなり異なります。 本家パッケージをインストールしたときにあった - `/etc/init.d/vboxautostart-service` - `/etc/init.d/vboxballoonctrl-service` - `/etc/init.d/vboxdrv` - `/etc/init.d/vboxweb-service` - `/etc/vbox` ディレクトリ が、Ubuntu 13.04 で apt でインストールした場合にはありません。 その代わり、 - `/etc/init.d/virtualbox` : `/etc/init.d/vboxdrv` の代わり - `/etc/defauult/virtualbox` があります。 `/etc/init.d/vboxautostart-service` が存在しませんので、代わりとして `/etc/rc.local` に `VBoxAutostart` を叩くコードを追加してみました。以下のような感じです。 binary=/usr/lib/virtualbox/VBoxAutostart /sbin/start-stop-daemon --background --chuid USER_NAME --start --exec $binary -- --background --start --config /etc/vbox/autostart.cfg `USER_NAME` の部分は、動かしたい仮想マシンの所有者に置き換えてください。 次に `/etc/vbox/autostart.cfg` を作り、以下の内容を記載。 default_policy = allow あとは自動起動したい仮想マシンの `VirtualBox VMs/VM_NAME/VM_NAME.vbox` を開き、以下のように1行追加。 <AttachedDevice passthrough="false" type="DVD" port="0" device="0"/> </StorageController> </StorageControllers> + <Autostart enabled="true" delay="0" autostop="Disabled"/> </Machine> </VirtualBox> ### Ubuntu 12.04LTS で apt-get でインストールした場合 ### Ubuntu 12.04 LTS で $ sudo apt-get install virtualbox でインストールした場合です。 VirtualBox のバージョンは 4.1.12 で `/usr/lib/virtualbox/VBoxAutostart` も存在しないので、上記のやり方は使えません。 `/etc/rc.local` に以下の行を追加しておきます。 su - USER_NAME -c "VBoxHeadless -startvm VM_NAME &" `USER_NAME` の部分はユーザー名に、`VM_NAME` の部分は動かしたいバーチャルマシンに置き換えてください。 というか、これが一番簡単かも。VirtualBox 4.2 以前でも使えるし。

Ubuntu 13.04 アップグレード後始末

[前回](/2013/06/raid-ubuntu.html)の記事で、Ubuntu 13.04 にアップグレードしました。 アップグレード後、ログイン時に以下のようなメッセージが出るようになりました。 Welcome to Ubuntu 13.04 (GNU/Linux 3.8.0-23-generic x86_64) * Documentation: https://help.ubuntu.com/ 0 packages can be updated. 0 updates are security updates. New release '13.04' available. Run 'do-release-upgrade' to upgrade to it. `Welcome to Ubuntu 13.04` と `New release '13.04' available` 矛盾していますね。 検索してみると、バグとして報告されているようです。 とりあえず、直し方は単純に以下のようにファイル1個消すだけでいいようです。 $ suro rm /var/lib/ubuntu-release-upgrader/release-upgrade-available `/etc/update-motd.d/91-release-upgrade` から呼ばれた `/usr/lib/ubuntu-release-upgrader/release-upgrade-motd` が必要に応じてまた作ってくれるみたいです。

RAID 上の Ubuntu をアップグレードする

Ubuntu 12.04 LTS から Ubuntu 13.04 にアップグレードしてみました。 マシンは、以前 [Linuxインストール on RAID (Intel RST)](/2012/09/linux-on-raid5-intel-rst.html) で書いた SDD 4 台で RAID5 構成です。 いきなり 13.04 にアップグレードできないので、 12.04 ⇒ 12.10 ⇒ 13.04 へとアップグレードすることにしますう。 アップデートマネージャーで 「設定...」を選び、 Ubuntu の新バージョンの通知: を「長期サポート(LTS)版」から「すべての新バージョン」へ変更する。 すると、「Ubuntu の新しいリリース '12.10'が利用可能です」というのが出てくる。 普通ならこれで簡単にアップグレードできるはずなのですが、困ったことに RAID を組んでいると、GUI でうまくアップグレードしてくれないみたいです。 Googleで調べつつやって、うまくいったので、やり方をまとめておきます。 とりあえず、アップデートマネージャーでアップグレードしていきました。 途中で、「起動デバイスへの GRUB の書き込みが失敗しました。続行しますか？」と出てくる。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgr4b_u5uBEv745EWcRgCZu0wQVRGMV0GmoBVVQ_T_fBlugq-6_sUjhWpmhXXyeGpaoUYwvOkUUqupJc_bu5ASNh3xV3v6I2ekoJy8Wx4656NpAPx7Xcdm-5SgEOMMS-dPGA7v55kI9hOk/s1600/grub-fail.png) とりあえず、続行ボタンを押して、後で手動で GRUB をインストールすることにする。 で、最後までいって、再起動する直前に端末から $ sudo grub-install /dev/mapper/isw_bdafdjfgcf_Volume0 Path `/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting. とやったのですが、失敗。ガビーン。 (`isw_xxxxxxxxxx_Volume0` の部分は人によって違うでしょう。) このまま再起動するも、やっぱり起動せず。 こういう困った時のために [Boot Repair](https://help.ubuntu.com/community/Boot-Repair) という素晴らしいツールがあります。 メディアに書き込んで、Boot Repair からブート。 起動したら「おすすめの修復」というのを選択。 途中で、「ターミナルを開いて、次のコマンドを入力（またはコピー&ペースト）してください。」という指示が出るので、言われるままに実行していきます。 最後にGRUBをインストールする画面が出てくるので 「/dev/mappder/isw_xxxxxxxxxx_Volume0」を選択します。 これで再起動すると、 Ubuntu 12.10 が起動するようになった。 困った時の Boot Repair 、覚えておこう。

Ubuntu Old Releases

何かで必要になった時のために。 - Warty Warthog Sounder: <http://releases.ubuntu.com/4.10/> - Hoary Hedgehog Array: <http://releases.ubuntu.com/5.04/> - Breezy Badger Colony: <http://releases.ubuntu.com/5.10/> - Dapper Drake Flight: <http://releases.ubuntu.com/6.06/> - Edgy Eft Knot: <http://releases.ubuntu.com/6.10/> - Feisty Fawn Herd: <http://releases.ubuntu.com/7.04/> - Gutsy Gibbon Tribe: <http://releases.ubuntu.com/7.10/> - Hardy Heron: <http://releases.ubuntu.com/8.04/> - Intrepid Ibex: <http://releases.ubuntu.com/8.10/> - Jaunty Jackalope: <http://releases.ubuntu.com/9.04/> - Karmic Koala: <http://releases.ubuntu.com/9.10/> - Lucid Lynx: <http://releases.ubuntu.com/10.04/> - Maverick Meerkat: <http://releases.ubuntu.com/10.10/> - Natty Narwhal: <http://releases.ubuntu.com/11.04/> - Oneiric Ocelot: <http://releases.ubuntu.com/11.10/> - Precise Pangolin: <http://releases.ubuntu.com/12.04/> - Quantal Quetzal: <http://releases.ubuntu.com/12.10/> - Raring Ringtail: <http://releases.ubuntu.com/13.04/>

FreeBSD のソースを git-svn で取ってきた

以前 [git-svn](/2012/10/git-svn.html) でも書いたのですが、プロジェクトの管理が cvs とか subversion とか聞いただけでも嫌になってしまう。 現在、FreeBSDは Subversion で管理されている。(以前は cvs だった。) リポジトリの構造が、Subversion標準の - trunk - branches - tags になっていれば、git に変換するときにわかりやすいんですが、 $ svn ls http://svn.freebsd.org/base で見てみると、そうはなっていないようです。 リポジトリの構造についての説明は - <http://people.freebsd.org/~peter/svn_notes.txt> - <http://www.freebsd.org/doc/en/articles/committers-guide/article.html#subversion-primer> - <http://svn.freebsd.org/base/ROADMAP.txt> にあたりに説明があるようですが、最後のリンクが一番わかりやすいと思う。 - base/head → trunk - base/stable → branches - base/releng → branches - base/release → tags という対応のようです。 (tags なのか branches なのかは、実はそれほど気にしなくてもよい。結局 git-svn で変換すると、 branches も tags も git 上ではブランチになってしまうので。) base/projects の下はトピックブランチのようなのですが、 base/projects/<topic> の下にさらに trunk と branches があったりして、ポリシーが一定していないので、変換はあきらめ。 他にも、 base/vendor, base/vendor-sys とかいくつかのワークエリアがあるようだが、これらも無視した。 というわけで、 $ git svn clone -T head -t release -b releng -b stable http://svn.freebsd.org/base freebsd_base という感じで変換して取って来ました。 途中何度か、サーバーのエラーか何かで止まったのですが、その度に `git svn fetch` で再開。 なんだか、むちゃくちゃ時間がかかる。しまった、 trunk だけにしとけばよかったか、と思いつつも、なんとか変換が終わりました。 (time コマンドで測ってみたが、58時間くらいかかった。。) ちなみに、 head -> stable/* -> releng/*.* -> release/*.*.* という風に、なっているので、基本的にブランチ(タグ)名はかぶらないようになっているはずなのだが、最初の頃はポリシーが徹底されていなかったのか、 `base/stable/2.0.5` と `base/releng/2.0.5` の名前がかぶっています。git に変換したときに 2.0.5 のブランチ名がかぶってしまうのですが、この処理がどうなっているのか不明。

FreeBSD 入門中 その4 : 環境整備2

[前回](/2013/06/freebsd-3.html)の続きです。 検索すればすぐ出てくるような内容ですが、いちいち調べ直すのも面倒なので、メモしてあります。 ### PAGER を lessに ### PAGER をデフォルトの more から less に設定します。 bash系: `~/.profile` で export PAGER=less C shell系: `~/.cshrc` または `~/.login` で setenv PAGER less とする。 (個人的には、環境変数は `~/.cshrc` よりも `~/.login` に書く方がよいと思っているが。。) ### sudo できるようにする ### Ubuntu に慣れていると、`sudo` できないと面倒に感じることがあります。 # pkg_add -r sudo でインストールする。 # visudo を実行して、 # %wheel ALL=(ALL) ALL となっている部分のコメントを外す。 設定ファイルはなぜか `/etc/sudoers` ではなく、 `/usr/local/etc/sudoers` にある。 ここから先は、一般ユーザーでログインしなおして、必要な時のみ、`sudo` で (もしくは `su` で rootに変身して)実行することにする。 ### NFS サーバー 設定 ### `sysinstall` で Configure -> Networking -> NFS Server 途中で、 `/etc/exports` を設定してください、とエディタが開くので設定を書く。 `/etc/exports` の書き方はコメント欄 (または `man exports`)を見ればわかる。 `/etc/rc.conf` に以下が追加されるはず。 nfs_server_enable="YES" rpcbind_enable="YES" `/etc/exports` を設定せずに ZFS の機能でやる方法もある。 例えば、 /homeディレクトリ以下を 192.168.xx.yy と 192.168.zz.ww へ公開する場合 # zfs set sharenfs="192.168.xx.yy 192.168.zz.ww" rpool/root/home のようにする。 `/etc/hosts` に記載したホスト名で指定はできなさそう。 あと `-network 192.168.11.0 -mask 255.255.255.0` みたいな書き方もできなさそうだし。 `/etc/exports` で設定したほうがよさそう。。 NAT経由のクライアントからマウントできるようにするには、 `/etc/rc.conf` に mountd_flags="-n" を書いておく。 ### Auto Mount ### 次は、NFS クライアントとしての設定。 `/net/` 以下にアクセスしたときに、自動で mount し、しばらくアクセスしないと自動で umount して欲しい。 Linux では autofs だったが、FreeBSD では AMD (auto mount daemon) というデーモンがあるらしい。 `sysinstall` して Configure -> Networking -> AMD にチェックを入れる。 AMD Flags はよくわからんが、デフォルトのままで使えた。 `/etc/rc.conf` に以下が追加されるはず。 amd_enable="YES" これでサーバー FOO が BAR というディレクトリで公開している場合、 `/net/FOO/BAR` にアクセスすると自動的にマウントしてくれるようになった。 ### Linux のバイナリを実行可能にする `/etc/rc.conf` に linux_enable="YES" を追加。 # pkg_add -r linux_base でインストール。 ### proc file system ### `/etc/fstab` に以下を追加 proc /proc procfs rw 0 0 ### ssh X port Forward ### `/etc/ssh/sshd_config` で X11Forwarding yes を有効にしてみるも、動かず。 後述の xorg をインストールしたときに、 `DISPLAY` 環境変数がセットされて、動くようになった。 よくわかりませんが、とりあえず動くようになりました。 ### X の設定 #### # pkg_add -r xorg でインストール。 /etc/rc.conf に hald_enable="YES" dbus_enable="YES" を追加する。 $ startx で起動する。 twm というWindow Manager が動く。 ### gnome ### # pkg_add -r でインストール。 `/etc/rc.conf` に gnome_enable="YES" を追加する。(gnome関連デーモン起動) システム起動時に gdm を起動させる場合は、 `/etc/rc.conf` に gdm_enable="YES" を追加。 `startx` で起動させる場合は $ echo "/usr/local/bin/gnome-session" > ~/.xinitrc $ startx ### pkgng ### pkg_* の代替ツール。 apt や yum みたいなもの。個人的には、必ずしも導入しなくてもよいと思う。 一応、[FreeBSD pkg_*システム捨てるのはいつ？今でしょ！](http://april.fool.jp/blogs/?p=1947) を参考に使ってみた。 最初に # pkg とやるとセットアップしてくれる。 `/etc/make.conf` に以下を追加。 WITH_PKGNG= yes すでに `pkg_*` を使っていた場合は `pkg2ng` でデータベースを移行。 現時点では、リポジトリがすっからかん(サーバーに侵入されたらしい)なので `/usr/local/etc/pkg.conf` を開き、 packagesite: http://pkgbeta.FreeBSD.org/freebsd:9:x86:64/latest をコメントアウトし、 packagesite: http://ftp.jaist.ac.jp/pub/PC-BSD/packages/9.1-RELEASE/amd64 を追加。 あとは、 `pkg install PACKAGE_NAME ...` でインストールしていく。 pkg install emacs とすると、`Conflict found on path` というエラーメッセージが大量に出てびっくりした。 `pkg install emacs` は複数のバージョンの emacs を一度にインストールしようとするらしく、 `pkg install emacs-24.3,3` みたいにバージョンまで入力しないといけないらしい。 apt や yum に比べると、このあたりは洗練されていない気がするなぁ。

FreeBSD 入門中 その3 : 環境整備

[前々回](/2013/06/freebsd-1-zfs-rootfs.html) zfs の Root File System にインストールするところまでできたので、 環境構築を行なっていきます。 標準のインストーラーを完全無視して進めたため、いろいろな設定が抜けています。 まだネットもつながらないし。。 ### rootパスワード設定 ### rootパスワードがまだ設定されていないので、ログインして `passwd` でパスワード設定しておく。 ### ネットワーク設定など ### `/etc` を直接編集してもいいけど typo の恐れがあるので、一応ツールでやります。 # sysinstall とし、Configure -> Networking -> Interfaces とたどって設定。 `/etc/rc.conf` に以下のような内容が追記される。 ifconfig_em0="DHCP" ipv6_activate_all_interfaces="YES" hostname=ernie.sesame" また `/etc/resolv.conf` には以下のような内容が追記される。 # Generated by resolvconf nameserver 192.168.11.1 他にもDNSサーバーがあれば追加する。 ### その他もろもろ ### `sysinstall` して Configure -> Networking -> sshd にチェックを入れる。 /etc/rc.conf に sshd_enable="YES" が追加される。 /etc/rc.conf に # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev="NO" も追記しておく。 crash dumpはお好みで "AUTO" に。 ### タイムゾーン設定 ### インストーラーを使わなかった場合、タイムゾーンの設定もまだなので、設定します。 `sysinstall` して Configure -> Time Zone を選ぶ。 UTC で Yes を選び、タイムゾーンは Asia -> Japan を選ぶ。 (`/usr/share/zoneinfo/Asia/Tokyo` が `/etc/localtime` へコピーされるらしい。) ### 時刻を合わせる ### ワンショットの `ntpdate` よりも `ntpd` を使う方が望ましいので、 `ntpd` を設定します。 `/etc/rc.conf` に以下を追加 ntpd_enable="YES" `/etc/ntp.conf` を開いて、 server 0.freebsd.pool.ntp.org みたいになっている部分を必要に応じて書き換える。(サーバーを変える必要があるとき。) ### パッケージインストール ### このままではまともに使えないぐらい、ソフトが入っていないので、サードパーティー製ツールを入れていきます。 環境によっては package を使用するのに、プロキシを乗り越えないといけない場合があります。 その場合 `FTP_PROXY` 環境変数を設定します。 システム全体に設定するために `/etc/profile` に export FTP_PROXY="http://your.proxy.server:port_number" のように書いておく。 ついでに `/etc/csh.login` にも setenv FTP_PROXY "http://your.proxy.server:port_number" のように書いておく。 # pkg_add -r bash nano vim emacs gmake cvs subversion git global autoconf automake libtool flex bison guile binutils gawk といった感じでインストール。 ### ログインシェル変更 ### bash好みの人は # chsh -s bash ### ports をセットアップ ### ports をセットアップ。 インストール時に入れなかった場合は、 /usr/ports ディレクトリがないと思います。 インスールメディアから ports をすでにインストールしている場合も、たぶん古いので、更新するのがよいです。 まず、snapshot を `/var/db/portsnap/` ディレクトリへダウンロードしないといけない。 プロキシのせいで # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... none found. Fetching public key from portsnap.FreeBSD.org... failed. No mirrors remaining, giving up. と出て失敗する場合は、環境変数 `HTTP_PROXY` を設定しておく。 export HTTP_PROXY="http://your.proxy.server:port_number" 最初に fetch する。 # portsnap fetch `/var/db/portsnap/` 以下にダウンロードされる。 続いて extract する。 # portsnap extract `/usr/ports` に展開される。 次回からは `portsnap fetch (portsnap cron)&& portsnap update` で更新する。 ### ユーザーアカウント作成 ### インストーラーを使わなかった場合、まだ一般ユーザーが作られていないため、作成します。 ユーザーアカウントを作る前に、 # zfs create /home/USER_NAME でユーザーのホームディレクトリ用にパーティションを切る。 これは必須ではないけれど、ZFS の運用では細かくパーティションを切るのがスタンダードのようだ。 (ユーザーのホームディレクトリ単位で、スナップショットとったりできる。) # adduser 質問に答えて行きながら、設定します。 管理者は Invite foo into other groups? []: と聞いてきたところに、`wheel` と入力する。 wheel グループに所属していないと、 `su` コマンドが使えないなど不自由するので。 ### グループを作成 ### 例えば、GID 2000 で gitusers というグループを作りたい場合 # pw groupadd gitusers -g 2000 次に、メンバーを group に加える。 例えば、 gitusers というグループに taro と hanako を加える場合は # pw groupmod gitusers -m taro,hanako とする。 [次回](/2013/06/freebsd-4-2.html)に続きます。

FreeBSD 入門中 その2: 壊して復旧する

[前回](/2013/06/freebsd-1-zfs-rootfs.html)、ZFS の RootFileSystem上に FreeBSD をインストールするところまでやりました。 インストールが無事終わったところで、さっそく壊しますか。（笑） せっかく ZFS にインストールしたのだから、試しに壊して復旧してみたくなりますね。（なりませんか？） 今回は、FreeBSD というよりも、ZFS の話題です。 Linux で ZFS を使おうとすると、 1. ZFS-FUSE: 機能が限定的 2. ZFS on LINUX: Kernel を更新するたびに、ZFSモジュールも再ビルドなので面倒 という欠点がありました。 （[Linux で ZFS を使ってみた](/2012/11/zfs.html) を参照） その点、FreeBSD では標準的にサポートされているのは良いですね。 ### 1台外してみる ### 今の構成は、HDD 4台で RAID-Z を構成しています。 ということは、HDD 1台壊れても起動できるはずです。 データが化けたくらいなら、 ZFS が scrub ですぐに直してくれますので、あまり面白くない。 HDDがうんともすんとも動かなくなって、もう取り外すしかないという状況になったという仮定でやってみます。 ernie0.vdi, ernie1.vdi, ernie2.vdi, ernie3.vdi という4台のHDDのうち、 図のように、 1台目の ernie0.vdi を取り外してみます。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrOtWJytN6efYndlKqf1Cpw7lTifwmWPJzQFHSISVIG-BlpE636iGKT6OIrARQZIgTukes5JfcazwyUDh6LnBbYEAS5RFr4cy9Y-9ClZjyBwhnaBs8FiTW_zs88MfhX6VPP3Klbd90v-8/s1600/raidz_1drive_missing.png) そして、起動させてみます。 なーんも問題なく起動しました。 これがうまく理屈としては、こうです。 前回のインストール時に、 4台すべての boot パーティションに、bootcode をインストールしてあります。 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 bootcode written to ada0 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1 bootcode written to ada1 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada2 bootcode written to ada2 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada3 bootcode written to ada3 なので、ブートローダーは問題なし。 Swap領域については、 # Device Mountpoint FStype Options Dump Pass# /dev/ada0p2 none swap sw 0 0 /dev/ada1p2 none swap sw 0 0 /dev/ada2p2 none swap sw 0 0 のように、認識された順に 3台だけ、使っています。 インストール時は - ada0: ernie0.vdi - ada1: ernie1.vdi - ada2: ernie2.vdi - ada3: ernie3.vdi のように認識していたわけですが、ernie0.vdi を取り外したので - ada0: ernie1.vdi - ada1: ernie2.vdi - ada2: ernie3.vdi のように認識するのですが、ドライブ番号で指定しているので、何ら矛盾はない。 で、ルートパーティションは RAID-Z になっていて冗長性が確保されているので、1台失われても問題ない。 (ちなみに ZFS の方は、認識順でドライブ番号が変わっておかしくならないように、ラベルで指定するのでした。) 当然、status を表示させると DEGRADED となっていますが。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikUpO9BjfjRejp52TiviSexgv64v19nm1BkEvvc5g5tXZ3yt7WAh81cNFouVZkEQ6pwOm4x4rAptN4ZwbzgnzuaNvqSCY6cvw1Bt5QxE3rlygCJnNgBXIcgUecNke5-k1OYqEYQL34ZIA/s1600/DEGRADED.png) ### 1台追加して復旧する ### このままでは、冗長性がなくて、心もとないので、新しいHDDを買ってきて接続したという想定にしましょう。 VirtualBox に新しく ernie4.vdi というディスクを追加しています。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCEhj48_6S7wx7bcAvzNIZd0_yg72vose4_EFYjr7D8ylA7OgY7GPZ9Y8wW_ZqrIZMYGA7_6bm87dfJD387tofuOYRtDX3TtT0KMO9D8F2PW_XSjvF2IvhFUJQAkzgsl9TQWQORoDV1F8/s1600/new_drive.png) 起動させて、他の3台と同じ構造で ernie4 にパーティションを切ります。 # gpart show -l => 34 33554365 ada0 GPT (16G) 34 122 1 ernie1_boot (61k) 156 1048576 2 ernie1_swap (512M) 1048732 32505667 3 ernie1_root (15G) => 34 33554365 ada1 GPT (16G) 34 122 1 ernie2_boot (61k) 156 1048576 2 ernie2_swap (512M) 1048732 32505667 3 ernie2_root (15G) => 34 33554365 ada2 GPT (16G) 34 122 1 ernie3_boot (61k) 156 1048576 2 ernie3_swap (512M) 1048732 32505667 3 ernie3_root (15G) # gpart create -s gpt ada3 # gpart add -s 122 -t freebsd-boot -l ernie4_boot ada3 ada3p1 added # gpart add -s 512m -t freebsd-swap -l ernie4_swap ada3 ada3p2 added # gpart add -t freebsd-zfs -l ernie4_root ada3 ada3p3 added # gpart show -l => 34 33554365 ada0 GPT (16G) 34 122 1 ernie1_boot (61k) 156 1048576 2 ernie1_swap (512M) 1048732 32505667 3 ernie1_root (15G) => 34 33554365 ada1 GPT (16G) 34 122 1 ernie2_boot (61k) 156 1048576 2 ernie2_swap (512M) 1048732 32505667 3 ernie2_root (15G) => 34 33554365 ada2 GPT (16G) 34 122 1 ernie3_boot (61k) 156 1048576 2 ernie3_swap (512M) 1048732 32505667 3 ernie3_root (15G) => 34 33554365 ada3 GPT (16G) 34 122 1 ernie4_boot (61k) 156 1048576 2 ernie4_swap (512M) 1048732 32505667 3 ernie4_root (15G) という感じになります。 4台対称にするために、 bootcode もインストールしておきます。 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada3 bootcode written to ada3 あとは `zpool replace` します。 # zpool replace rpool /dev/gpt/ernie0_root /dev/gpt/ernie4_root Make sure to wait until resilver is done before rebooting. `zpool status` で resilvered になっていたら OKです。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiUZCASEfwFnFjJM9_PMuR6PkcodpI45vQjsaF9bEgUJiMI-oXXIAOW6ZxOcEBaXIJDskw45Zh3IxgDpXXiUFdr3wyTt41PyEUxh-_PO_RaCdDI7BwuIy4iej8Wu9oyjIckBHCGZ-mZSCY/s1600/resilvered.png) これで冗長性が確保されたので、またどれか1台取り外しても、何の問題なく起動します。 ZFS 素晴らしすぎる。 [次回](/2013/06/freebsd-3.html)は、まともに使えるようにいろいろとセットアップしていきます。

FreeBSD 入門中 その1 : ZFS RootFS にインストール

FreeBSD にはあまり興味はなかったのですが、仕事の都合で FreeBSDをインストールすることになりました。 というわけで、 Linux の知識はあれども、FreeBSD の知識は皆無な状態からスタートして、インストールや環境設定などやっていきます。 今回はインストールするところまでやってみます。 ### インストールメディア入手 ### 現時点では 9.1 が最新。 以下からインストールメディアを入手できる。 <http://www.freebsd.org/ja/> FreeBSD-9.1-RELEASE-amd64-dvd1.iso をダウンロードしてきた。 (やたらと時間かかった。BitTorrentとかないのかね。) 入門中といいつつ、通常のインストーラーをいきなり無視します。(笑) 理由は RootFileSystem をZFSにしたいから。 やり方は以下のサイトで詳しく書かれているので、参考になります。 [FreeBSD 9.1-RELEASE で ZFS Root FileSystem 環境を構築する](http://kanjuku-tomato.blogspot.jp/2013/01/freebsd-91-release-zfs-root-filesystem.html) このサイトをかなり参考にしているのですが、自分は HDD 4台で RAID-Z (いわゆるRAID 5) で組んでみました。 HDD 1台だと ZFS を使う意味の大半がなくなってしまいますから。。 それから、不要な手順をいくつかはしょって自分流にアレンジしてます。 ### マシン(VirtualBox) 設定 ### マシンですが、VirtualBox を使っています。 SATA に HDDを4台、IDE に CD/DVDドライブを1台つなぎました。 CD/DVDドライブ も SATAにすると、インストールメディアからブートできませんでしたので。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjiQtfTo4azn9zXzCKKwYqKvxLblt5m-5kAEhTrl3zKC2GybdVGa6oO6d7GCfipy62JvHaHqYYg6mmhLTrabHKlPAxZ38nkynQ_wh_8jByTKtycIKtQyaeu-fMT0Y92tsGHIEMJfd3agIE/s1600/bsd_virtualbox.png) さらに、設定 → システム で 「ハードウェアクロックをUTCにする」にチェックを入れておきます。 FreeBSD は UTC で運用するので、これをチェックしておかないと、時刻が9時間ずれます。 以下の説明では、セットアップするマシンのホスト名は ernie とします。 余談ですが、自分の家ではホスト名に elmo, cookie, bigbird, oscar, zoe などと Sesame Street のキャラクター名を付けていっています。 一定のネーミングルールを決めておくと、ホスト名がどんどん増えても名前に困りません。 ### インストール開始 ### インストールメディアからブートさせます。 Welcome to FreeBSD の画面で 「1. Boot (Enter)」を選択。 インストーラーが起動するので 1. [Welcome]: <Install> を選択 2. [Keymap Selection]: <Yes> を選択 3. [Keyboard Menu]: Japanese 106 を選択 4. [Set Hostname]: 適当に何か入れる (途中からインストーラ無視するので、どうせ /etc に反映されない。) 5. [Distribution Select]: そのまま <OK> でよし 6. [Partitioning]: <Shell> を選択 ### パーティションテーブル作成 ### シェルに入るので、ここからインストーラー無視して、自分でセットアップします。 `/dev` を見るとハードディスクは `/dev/ada0`, `/dev/ada1`, `/dev/ada2`, `/dev/ada3` として認識されています。 この4台にパーティションを作るところから始めます。 以下のように、GUIDパーティションテーブルを作る。 # gpart create -s gpt ada0 ada0 created # gpart create -s gpt ada1 ada1 created # gpart create -s gpt ada2 ada2 created # gpart create -s gpt ada3 ada3 created ### パーティション作成 ### ブートパーティション、スワップ領域、ZFS領域を作成します。 raidz (いわゆる RAID5)にするので、4台とも同じ構造でパーティション作るのがわかりやすそうです。 ラベル名はかぶらないようにしましょう。 # gpart add -s 122 -t freebsd-boot -l ernie0_boot ada0 ada0p1 added # gpart add -s 122 -t freebsd-boot -l ernie1_boot ada1 ada1p1 added # gpart add -s 122 -t freebsd-boot -l ernie2_boot ada2 ada2p1 added # gpart add -s 122 -t freebsd-boot -l ernie3_boot ada3 ada3p1 added # gpart add -s 512m -t freebsd-swap -l ernie0_swap ada0 ada0p2 added # gpart add -s 512m -t freebsd-swap -l ernie1_swap ada1 ada1p2 added # gpart add -s 512m -t freebsd-swap -l ernie2_swap ada2 ada2p2 added # gpart add -s 512m -t freebsd-swap -l ernie3_swap ada3 ada3p2 added # gpart add -t freebsd-zfs -l ernie0_root ada0 ada0p3 added # gpart add -t freebsd-zfs -l ernie1_root ada1 ada1p3 added # gpart add -t freebsd-zfs -l ernie2_root ada2 ada2p3 added # gpart add -t freebsd-zfs -l ernie3_root ada3 ada3p3 added # gpart show => 34 33554365 ada0 GPT (16G) 34 122 1 freebsd-boot (61k) 156 1048576 2 freebsd-swap (512M) 1048732 32505667 3 freebsd-zfs (15G) => 34 33554365 ada1 GPT (16G) 34 122 1 freebsd-boot (61k) 156 1048576 2 freebsd-swap (512M) 1048732 32505667 3 freebsd-zfs (15G) => 34 33554365 ada2 GPT (16G) 34 122 1 freebsd-boot (61k) 156 1048576 2 freebsd-swap (512M) 1048732 32505667 3 freebsd-zfs (15G) => 34 33554365 ada3 GPT (16G) 34 122 1 freebsd-boot (61k) 156 1048576 2 freebsd-swap (512M) 1048732 32505667 3 freebsd-zfs (15G) # gpart show -l => 34 33554365 ada0 GPT (16G) 34 122 1 ernie0_boot (61k) 156 1048576 2 ernie0_swap (512M) 1048732 32505667 3 ernie0_root (15G) => 34 33554365 ada1 GPT (16G) 34 122 1 ernie1_boot (61k) 156 1048576 2 ernie1_swap (512M) 1048732 32505667 3 ernie1_root (15G) => 34 33554365 ada2 GPT (16G) 34 122 1 ernie2_boot (61k) 156 1048576 2 ernie2_swap (512M) 1048732 32505667 3 ernie2_root (15G) => 34 33554365 ada3 GPT (16G) 34 122 1 ernie3_boot (61k) 156 1048576 2 ernie3_swap (512M) 1048732 32505667 3 ernie3_root (15G) 間違いがないことを確認して次に進みます。 ### ブートコードインストール ### 各ドライブの1番目のパーティション(freebsd-boot)にブートコードをインストール。 とりあえず全ドライブにブートコードを書いておけば、どれかぶっ壊れても起動できると思う。 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 bootcode written to ada0 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1 bootcode written to ada1 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada2 bootcode written to ada2 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada3 bootcode written to ada3 ### ZFS 作成 ### zpool を作ります。 altroot は一時的なマウントポイントで、再起動するとこの情報は持ち越されない。 また、 `/dev/ada0p2` のようにパーティションを指定すると、マウント順でドライブ番号が変わる可能性があるので、 一意に決まるラベルで指定するのがよいです。 cachefile を一時保存する領域を設けるため、 tmpfs をマウントしておく。 # mount -t tmpfs tmpfs /tmp # zpool create -f -o altroot=/media -o cachefile=/tmp/zpool.cache rpool raidz \ /dev/gpt/ernie0_root /dev/gpt/ernie1_root /dev/gpt/ernie2_root /dev/gpt/ernie3_root ZFS filesystem version 5 ZFS storage pool version 28 # zfs create rpool/root # zfs create rpool/root/var # zfs create rpool/root/home # zpool set bootfs=rpool/root rpool # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 306K 45.3G 44.9K /media rpool/root 133K 45.3G 46.4K /media/root rpool/root/home 43.4K 45.3G 43.4K /media/root/home rpool/root/var 43.4K 45.3G 43.4K /media/root/var ちなみに、 `zpool` コマンドを実行した時に ZFS filesystem version 5 ZFS storage pool version 28 というメッセージが出ていますが、これは zfs module が自動的にロードされているからです。 pool 直下にもファイルは作れるが、やらないほうがいいそうです。 なので、以下のようにする。 # zfs set mountpoint=none rpool # zfs set mountpoint=/ rpool/root # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 317K 45.3G 44.9K none rpool/root 133K 45.3G 46.4K /media rpool/root/home 43.4K 45.3G 43.4K /media/home rpool/root/var 43.4K 45.3G 43.4K /media/var ### インストールメディアから展開 ### # tar xzpf /usr/freebsd-dist/base.txz -C /media/ # tar xzpf /usr/freebsd-dist/kernel.txz -C /media/ # tar xzpf /usr/freebsd-dist/ports.txz -C /media/ # tar xzpf /usr/freebsd-dist/src.txz -C /media/ # tar xzpf /usr/freebsd-dist/doc.txz -C /media/ ### 設定ファイル作成 ### 自力で設定ファイルを作っていきます。 `vi` などで以下のように記述します。 `/media/boot/loader.conf`を作って以下のように記載 zfs_load="YES" vfs.root.mountfrom="zfs:rpool/root" `/media/etc/rc.conf`を作って以下のように記載 zfs_enable="YES" keymap="jp.106.kbd" `/media/etc/fstab`を作って以下のように記載 # Device Mountpoint FStype Options Dump Pass# /dev/ada0p2 none swap sw 0 0 /dev/ada1p2 none swap sw 0 0 /dev/ada2p2 none swap sw 0 0 ### キャッシュファイルをコピー ### # cp /tmp/zpool.cache /media/boot/zfs/ # zpool set cachefile="" rpool ### 最終チェック(いちおう) ### ZFSで起動できるかチェックするスクリプトがあるらしいので、インストールして実行する。 # cd /media/usr/src/tools/tools/zfsboottest # make # make DESTDIR=/media install install -s -o root -g wheel -m 555 zfsboottest /media/usr/bin install -o root -g wheel -m 555 zfsboottest.sh /media/usr/bin/zfsboottest.sh # env PATH=$PATH:/media/usr/bin zfsboottest.sh rpool The "mountpoint" property of dataset "rpool/root" should be set to "legacy". どうも、 `rpool/root` のマウントポイントを `/` から `legacy` に変更せよ、と言っています。 ZFS は標準では、 `/etc/fstab` を使わないのですが、 `legacy` というのは、従来通り `/etc/fstab` で管理するモードのこと。 で、せっかくの忠告ですが、無視します。(笑) 最初は忠告にしたがって、 `zfs set mountpoint=legacy rpool/root` とかやっていたのですが、別にやらなくても問題なく起動できることがわかったので。 忠告無視して、そのまま電源OFFします。 # sync # halt -p ### インストール完了、そして再起動 ### CD/DVDドライブからインストールメディアを取り除いて、起動します。 さて、本当に起動するか、ドキドキですが。。無事起動しました。 ZFS が期待通りか確認。 # zfs get mountpoint NAME PROPERTY VALUE SOURCE rpool mountpoint none local rpool/root mountpoint / local rpool/root/home mountpoint /home inherited from rpool/root rpool/root/var mountpoint /var inherited from rpool/root # zfs get mounted NAME PROPERTY VALUE SOURCE rpool mounted no 　 - rpool/root mounted yes/ - rpool/root/home mounted yes - rpool/root/var mounted yes - swap 領域を確認してみる。 # pstat -s Device 1K-blocks Used Avail Capacity /dev/ada0p2 524288 0 524288 0% /dev/ada1p2 524288 0 524288 0% /dev/ada2p2 524288 0 524288 0% Total 1572864 0 1572864 0% 大丈夫そう。 次回、設定をしていきます。

solarized

目にやさしい solarized というのを使ってみました。 とりあえず emacs に導入してみた。 Ubuntu でセットアップした時のメモです。 emacs23 に color theme というのを入れる必要があるようなので $ sudo apt-get install emacs-goodies-el でインストール。 <https://github.com/altercation/solarized/blob/master/emacs-colors-solarized/color-theme-solarized.el> にアクセス。 Rawボタンを右クリックして 「ボタンを右クリックして リンク先を別名で保存...」。 とりあえず、 `~/.emacs.d/elisp/color-theme-solarized.el` に保存したとする。 `~/.emacs` に以下を書いておく。 (load-file "~/.emacs.d/elisp/color-theme-solarized.el") (when (require 'color-theme-solarized)   (color-theme-solarized-light)) [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi36UzwgWLQDf6GoLtgrZIRMym2c-iqBU3dGComSF5SvOHDzp8ih_tkE-LQvBLczb6srYPUh3KqHaQPPnO1FTyUs_gUkhh4bKcoocucPHR4s7g8rSpfu3O4N1Iy2sjL1kN0xCZPuvEX3xw/s1600/Screenshot_from_2013-06-04+01:14:13.png) (when (require 'color-theme-solarized)   (color-theme-solarized-dark)) にするとこんな感じ。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSvsJ_H6a3QbVDkzM7s5J_KtcG-_dCFahoM95oIG_1Npoy59D5za5tJXLTUqJNV17z3vzQIBKOK9jC9mdODsy8hoSLj-5b9wYamzgkQ0LHN2kpaYwMxpFG0VgHiYz4G_WerCs_YGDgz0M/s1600/Screenshot_from_2013-06-04+01%253A14%253A32.png)

パッチを投稿しよう！

オープンソースをダウンロードしてきて、動かしたり、改造したりしているうちに、
バグ修正や、新機能などをコミュニティへフィードバックしたくなってくるかもしれません。

自分は、最近 U-Boot によくパッチを投稿しています。

以下は、U-Boot にパッチを送り始めた時に自分がやった時の一連の流れをまとめておきます。
U-Boot は基本的に、Linux Kernel と同じ開発スタイルを踏襲しているので、それなりに参考になるかと。

ML に参加する

たいていは、パッチはメーリングリストに投稿するようになっていると思います。
なので、まずはメーリングリストを購読します。
やり方は、開発のコミュニティのページに書いてあります。

git send-email を使えるようにする

これについては、前回、git send-email でまとめておきました。

投稿用のパッチを作る

パッチの作り方は、コミュニティのページに説明があると思います。
ログの入れ方とか、いろいろと取り決めがあるので、じっくり読みます。

Linux Kernel を始め、いくつかのコミュニティでは sign-off という制度があります。
sign-off とは、このパッチはオープンソースとして提供しても大丈夫なものですよ、ということを私が証明します、という意味だと、自分なりに理解しています。

自分が一から書いたパッチであれば当然問題はないです。
パッチの中に、別の GPL のコードを含んでいても問題はないです。
一方、GPL とは相容れないライセンスのコードを含んでいたら、NGです。

コミット時に

$ git commit -s

のようにすれば、ログに Signed-off-by: ～ という行が追加されます。

パッチ生成時に

$ git format-patch -s

のようにしてもいいですが、忘れないように commit 時にやっておくのがいいように思います。

パッチ送る

前回 はとりあえず練習で自分宛に送りましたが、いよいよ今度は本物のメーリングリストに送ります。
初めてパッチを送信する時は、結構ドキドキするものです。

毎回送信先のアドレスを聞いてこないように

$ git config sendemail.to mailing-list

の設定をします。プロジェクトごとに送信先が違うはずなので、--global オプションは付けません。そうすると、この設定はリポジトリごとの .git/config に書き込まれます。

git send-email で送ります。

初回の投稿の場合、 Message-ID to be used as In-Reply-To for the first email?
については、そのまま [Return] でよいです。

自分のパッチが受け付けられたことを確認する

送信するのが初めての場合、すぐにメーリングリストに配信されずに

Your message to <...> awaits moderator approval

みたいな返信が来ることがあります。

一瞬、なんじゃこりゃ？みたいに思うかもしれませんが、心配いりません。

たぶん、スパム対策のために、初めて投稿してくる人に対しては、まともな内容かどうか審査があるんだと思います。
問題なければ、数時間後にはメーリングリストに配信されてくると思います。

2回目からは、すぐにメーリングリストに配信されると思います。

パッチのステータス管理に Patchwork http://patchwork.ozlabs.org/ というシステムを使っているプロジェクトもあります。
自分のパッチもステータス New として登録されていることを確認します。

レビューに対し、返答する

自分のパッチに対し、フィードバックしてくれる人があるかもしれません。
これに対しては、 git send-email ではなくて、普段使っているメーラーで、ごく普通に返信します。

修正版のパッチを再投稿する

投稿したパッチがそのまま Accepted になれば万々歳です。
Rejected になれば、基本的にはそこで終わりです。
Changes Requested になった場合は、指摘された部分を修正することで、Accepted になる可能性が高いです。

この場合、元のスレッドに対して修正版のパッチを返信するのではありません。
(Changes Requested になれば、そのスレッドは基本的に終わりです。)

新しいパッチファイルを作り直し、投稿します。

修正をしたら、

$ git commit --amend

でコミットを作り直します。

そして、今度はVersion 2のパッチであることがわかるようにタイトルに入れます。
以下のようにすれば git がやってくれます。

$ git format-patch --subject-prefix="PATCH v2" HEAD^

さらに、前回のパッチからどこが変わったのかをパッチの中に書き込みます。

$ nano 0001-blabla-blablabla


Signed-off-by: ～ の直後に

---

という行があって、この直後にコメントを入れることができます。
これは git のコミットログには反映されません。
例えば、以下のような感じです。

Signed-off-by: Masahiro Yamada <abc@xyz.com>
---

Changes for v2:
   - Fix hogehoge

git send-email で送りますが、今度は
Message-ID to be used as In-Reply-To for the first email?
のところに、前回のバージョンのパッチの Message-ID（前回のメールのヘッダを見れば書いてある）を入力します。
これによって、スレッドで関連付けられます。

git send-email

git には send-email というメールを送信するコマンドがあります。
ただし、普通のメールを送信するのに使うというより、パッチを送る用途に使います。

パッチを自分のメーラーに貼りつけて送信してもいいのですが、
メーラーによっては、長い行を勝手に改行してくれたりして、パッチが破壊される可能性もあります。

リポジトリ管理に git を使っているプロジェクトだと、
git format-pach でパッチ生成 ⇒ git send-email で送信
とするのが手順的にも楽です。
オープンソースの開発にコントリビュートするのに必須ですね。

セットアップについてメモ。

git-core を入れただけでは、 git send-email コマンドはまだ入っていないかもしれません。

Ubuntu の場合は

# apt-get install git-email

でインストールできます。
(他のディストリビューション未確認)


まずは練習のために、自分宛に、何か送ってみましょう。

なんでもいいので、git リポジトリでパッチを生成します。

$ git format-patch HEAD^
0001-blabla-blablabla.patch

今生成したパッチを送信してみます。

$ git send-email 0001-blabla-blablabla.patch
0001-blabla-blablabla.patch
Who should the emails appear to be from? [Masahiro Yamada <abc@xyz.com>]
Emails will be sent from: Masahiro Yamada <abc@xyz.com>
Who should the emails be sent to? abc@xyz.com
Message-ID to be used as In-Reply-To for the first email?

みたいな感じになります。

Who should the emails appear to be from?
というのは、メールの送信元 (From: フィールド) のことです。
基本的にコミットログからとってくれるので、それでよければそのまま [Return] を押します。

Who should the emails be sent to?
は送り先です。
今は練習なので、自分のメールアドレスを入れます。

Message-ID to be used as In-Reply-To for the first email?
は、今から送るメールが、何か別のメールに対する返信であるときに、引用元の Message-ID を入れておくと、メーラーなどがスレッドの分類などに使ってくれます。
今は、新規メールですので、そのまま [Return] でよいです。

最後に

Send this email? ([y]es|[n]o|[q]uit|[a]ll): y

と聞いてきますので、 間違いがないか確認して、 y[Return]
とします。

ローカルで sendmail 系のサービスが動いていれば、これで送信できちゃいます。
自分は postfix を入れています。postfix の設定は以前、git push でメールをとばす で簡単にまとめた。

postfix など入れてないケースが多いでしょうが、その場合は SMTPサーバーを指定しないといけません。

$ git config --global sendemail.smtpserver server_address
で設定します。必要であれば
$ git config --global smtpserverport port_number
でポート番号を設定します。

プロジェクトごとに別の SMTP サーバーを使う必要は普通はないので、--global オプションを付けます。すると、この設定は ~/.gitconfig に書き込まれます。


特に Gmail を使って送信する方法もメモっておきます。
GitTips に書いてありました。

~/.gitconfig/に以下を追加

[sendemail]
        smtpencryption = tls
        smtpserver = smtp.gmail.com
        smtpuser = your_account@gmail.com
        smtpserverport = 587

を追加して、 git send-email を実行すると Password を聞いてくるので、Gmail のパスワードを入力すると送信できる。

この場合の注意点は、git send-email での表示と無関係に、メールの From フィールドを
smtpuser = your_account@gmail.com で指定したアドレスに強制的に置き換えてしまうことです。

vnc で Ubuntu をリモート操作

Ubuntu でデスクトップをリモート操作します。 動作確認は Ubuntu 12.04 LTS と Ubuntu 13.04 でしました。 「お手軽編」と「ちゃんとする編」を紹介します。 ### お手軽編 ### vino(サーバー) と remmina (クライアント) を使います。 どちらも、たぶんデフォルトで入っていると思うので、インストールするパッケージはなし。 #### サーバー側 #### サーバー側で vino の設定をします。 メニューから「システムツール」 -> 「設定」 -> 「デスクトップの共有」を選びます。 (自分は Unity が好きではないので、 `gnome-session-fallback` を入れている。) 端末から起動する場合は $ vino-preferences と入力すると、設定ダイアログが出てくる。 「他のユーザーが自分のデスクトップを表示できる」と「他のユーザーがデスクトップを操作できる」にチェックを入れます。 「このマシンへの接続を毎回確認する」はチェックを外しておいた方がよいでしょう。 これにチェックが入っていると、クライアントから接続するときに、サーバー側に「別のユーザーがお使いのデスクトップを参照しているようです。許可しますか？」というダイアログが出てきます。 わざわざ、サーバー側まで歩いて行って、許可ボタンを押していると、遠隔操作の意味がほとんどなくなってしまいます。 誰でもデスクトップを操作できるのはよろしくないので、「パスワードの入力を要求する」にチェックをいれておくのがよいでしょう。このパスワードは、ログインパスワードとは別のようです。 #### クライアント側 #### それでは、クライアント側から接続してみます。 クライアント側のメニューで「インターネット」 -> 「Remmin リモートデスクトップ・クライアント」 を選びます。 もしくは端末から起動するなら $ remmina と入力します。 ダイアログが開くので、プロトコルから「VNC - 仮想ネットワークコンピューティング」を選びます。 あとは、「サーバー」と「ユーザー名」を入力して、「接続」ボタンを押すと接続できます。 「サーバー」の欄はホスト名かIPアドレスを入れます。「:0」は付けても付けなくてもよい。 #### 問題点 #### 以上で、とりあえずリモート操作はできるのですが、これでは問題もあります。 vino は daemon ではないので、サーバー側でユーザーがログインしてすでにデスクトップを表示していないと、クライアントからは接続できません。 つまり、デスクトップにログインするときはサーバーのところまで歩いていって、直接操作しないといけません。 ディスプレイマネージャーからログインできるようにするには、以下で紹介する方法を取ります。 ### ちゃんとやる編 ### #### サーバー側 #### サーバー側は x11vnc を使います。 $ sudo apt-get install x11vnc xinetd を入れる。 `/etc/xinetd.d/x11vnc` を以下の内容で作成する。 service x11vnc { type = UNLISTED disable = no socket_type = stream protocol = tcp wait = no user = root server = /usr/bin/x11vnc server_args = -inetd -o /var/log/x11vnc.log -display :0 -forever -bg -rfbauth /etc/vncpasswd -shared -enablehttpproxy -forever -nolookup -auth /var/run/lightdm/root/:0 port = 5900 flags = IPv6 } x11vncのパスワード設定 $ sudo x11vnc -storepasswd /etc/vncpasswd Enter VNC password: Verify password: Write password to /etc/vncpasswd? [y]/n y Password written to: /etc/vncpasswd xinetd を再起動 $ sudo service xinetd restart 念のため `netstat` で確認して 5900番をLISTENしていたら、サーバー側の設定はOKです。 $ netstat -a | grep 5900 tcp6 0 0 [::]:5900 [::]:* LISTEN #### クライアント側 #### クライアント側は、「お手軽編」で説明したのと同じで、 remmina で接続できます。 環境によるのでしょうが、たまに接続したと思ったらいきなりウィンドウが閉じて終了していまうことがありました。 remmina の「色数」のところが「256色」になっていると、異常終了することがあったので、最低でも「High color (15bit)」の設定にしました。 Ubuntu 12.04LTS にはないようですが、Ubuntu 13.04 には `vncviewer` というクライアントがあるようです。 $ sudo apt-get install vncviewer でインストールします。 $ sudo vncviewer HOST_NAME だけで使えます。なかなか使いやすいです。

RAM を一切使わずにプリントデバッグ

Linux Kernel のコードを見ていると、
arch/arm/kernel/debug.S にかなりローレベルなプリントデバッグ用のサブルーチンがありますね。

これをちょっと真似して、より少ない資源で、ARM の起動初期のプリントデバッグができるように改良したものを作ってみました。

printhex2: 2桁の16進数を表示する
printhex4: 4桁の16進数を表示する
printhex8: 8桁の16進数を表示する
printunsigned: unsigned な10進数を表示する
printsigned: signed な10進数を表示する
printascii: 文字列表示
printch: 一文字表示

表示したい数値もしくは文字列を r0 にセットして、上記のマクロを call すれば使えます。

printhex2, printhex4, printhex8, printascii, printch は Linux Kernelにもあるのですが、
Linux Kernel に含まれているバージョンとの違いは
RAM を一切使用せず、破壊するレジスタは r0, r1, r2, r3のみです。
printunsigned と printsigned はオリジナルで作りました。

これら用途としては、ブートのかなり初期で、RAM もまだ使えない状態で、簡単にプリントデバッグしたいときのために作ったものなのです。
(LEDぐらいしか点灯しないとなるとかなりデバッグが苦しいですので。)
私は U-Boot で lowlevel_init 関数とかのデバッグ用途に使っていました。


以下、コードです。

レジスタビューは 16550 を想定してます。
最初に early_serial_initを call する必要があります。
DEBUG_UART_BASE, UART_SHIFT, DIVISOR あたりは自分の環境に合わせて変更して下さい。

---

#define DEBUG_UART_BASE    0xXXXXXXXXX
#define UART_SHIFT 1

/*
 * DIVISER = ((BAUDCLK / 8 / BAUDRATE + 1) / 2)
 */
//#define DIVISOR  40 /* 19200 bps */
//#define DIVISOR  20 /* 38400 bps */
#define DIVISOR  7 /* 115200 bps */

#define UART_TX  0 /* Out: Transmit buffer */

#define UART_LCR 3 /* Out: Line Control Register */
#define UART_LCR_DLAB  0x80 /* Divisor latch access bit */
#define UART_LCR_WLEN8  0x03 /* Wordlength: 8 bits */

#define UART_LSR 5 /* In:  Line Status Register */
#define UART_LSR_TEMT  0x40 /* Transmitter empty */
#define UART_LSR_THRE  0x20 /* Transmit-hold-register empty */

/*
 * DLAB=1
 */
#define UART_DLL 0 /* Out: Divisor Latch Low */
#define UART_DLM 1 /* Out: Divisor Latch High */


/*
 * Call the routine once
 * before calling printhex8/4/2, printascii, printch.
 */
ENTRY(early_serial_init)
  addruart r3
  mov r0, #UART_LCR_DLAB
  strb r0, [r3, #UART_LCR << UART_SHIFT]
  mov r0, #(DIVISOR & 0xff)   @ LSB of divisor
  strb r0, [r3, #UART_DLL << UART_SHIFT]
  mov r0, #((DIVISOR >> 8) & 0xff) @ MSB of divisor
  strb r0, [r3, #UART_DLM << UART_SHIFT]
  mov r0, #UART_LCR_WLEN8
  strb r0, [r3, #UART_LCR << UART_SHIFT]
  mov pc, lr
ENDPROC(early_serial_init)


  .macro addruart, rx
  ldr \rx, =DEBUG_UART_BASE
  .endm

  .macro senduart,rd,rx
  strb \rd, [\rx, #UART_TX << UART_SHIFT]
  .endm

  .macro busyuart,rd,rx
1002:  ldrb \rd, [\rx, #UART_LSR << UART_SHIFT]
  and \rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
  teq \rd, #UART_LSR_TEMT | UART_LSR_THRE
  bne 1002b
  .endm

/*
 * Useful debugging routines
 *
 * printhex8, printhex4, printhex2:
 *  print a number in 8, 4, 2 digits hexadecimal, respectively.
 *  r0 = number
 *  r1-r3 corrupted
 *
 * printunsigned, printsigned
 *  print a number in decimal.
 *  r0 = number
 *  r1-r3 corrupted
 *
 * printascii
 *  print a string
 *  r0 = pointer to string
 *  r0-r3 corrupted
 *
 * printch
 *  print a character
 *  r0 = character code
 *  r0-r3 corrupted
 */
ENTRY(printhex8)
  mov r2, #28
  b printhex
ENDPROC(printhex8)

ENTRY(printhex4)
  mov r2, #12
  b printhex
ENDPROC(printhex4)

ENTRY(printhex2)
  mov r2, #4
printhex:
  addruart r3
1:  mov r1, r0, lsr r2
  and r1, r1, #15
  cmp r1, #10
  addlt r1, r1, #'0'
  addge r1, r1, #'a' - 10
  senduart r1, r3
  busyuart r1, r3
  subs r2, r2, #4
  bge 1b
  mov pc, lr
ENDPROC(printhex2)

ENTRY(printunsigned)
  mov r1, #1
  mov r2, #0
1:  mov r1, r1, lsl #1  @ r1 = 2 * r1
  add r1, r1, r1, lsl #2 @ r1 = 5 * r1
  add r2, r2, #1
  cmp r2, #10   @ prevent overflow of r1
  bge 2f
  cmp r1, r0
  bls 1b
2:  mov r3, r2   @ number of digits
3:  mov r1, #1
  mov r2, #0
4:  add r2, r2, #1
  cmp r2, r3
  movlt r1, r1, lsl #1  @ r1 = 2 * r1
  addlt r1, r1, r1, lsl #2 @ r1 = 5 * r1
  blt 4b
  mov r2, #0
5:  cmp r1, r0
  subls r0, r0, r1
  addls r2, r2, #1
  blo 5b
  add r2, r2, #'0'
  addruart r1
  senduart r2, r1
  busyuart r2, r1
  subs r3, r3, #1
  bgt 3b
  mov pc, lr
ENDPROC(printunsigned)

ENTRY(printsigned)
  cmp r0, #0
  bge printunsigned  @ signed greater or equal
  addruart r3
  mov r1, #'-'
  senduart r1, r3
  busyuart r1, r3
  rsb r0, r0, #0  @ r0 = 0 - r0
  b printunsigned
ENDPROC(printsigned)

ENTRY(printascii)
  addruart r3
  b 2f
1:  senduart r1, r3
  busyuart r2, r3
  teq r1, #'\n'
  moveq r1, #'\r'
  beq 1b
2:  teq r0, #0
  ldrneb r1, [r0], #1
  teqne r1, #0
  bne 1b
  mov pc, lr
ENDPROC(printascii)

ENTRY(printch)
  addruart r3
  mov r1, r0
  mov r0, #0
  b 1b
ENDPROC(printch)

バイナリファイルを逆アセンブル

elf とかではなく、バイナリーイメージになっている場合。 i386の場合 $ objdump -b binary -m i386 -D foo.bin ARMの場合 $ arm-none-eabi-objdump -b binary -m arm -D foo.bin でできた。

アドレスサイズプレフィックス、オペランドサイズプレフィックス

GNU assemblerの話。
.code16, .code32, .code64でそれぞれ 16bit, 32bit, 64bit モードでアセンブルしてくれるようです。

まず、レジスタの名前ですが、ビット長ごとに以下の通り。
16bit  32bit  64bit
%ax    %eax   %rax
%bx    %ebx   %rbx
%cx    %ecx   %rcx
%dx    %edx   %rdx
%si    %esi   %rsi
%di    %edi   %rdi



例えば、以下のような test.s というファイルを作る。


.file "test.s"
.text

.code16
main16:
mov (%si), %ax
mov (%si), %eax
mov (%esi), %ax
mov (%esi), %eax

.code32
main32:
mov (%si), %ax
mov (%si), %eax
mov (%esi), %ax
mov (%esi), %eax

.code64
main64:
// mov (%si), %ax
// mov (%si), %eax
// mov (%si), %rax
mov (%esi), %ax
mov (%esi), %eax
mov (%esi), %rax
mov (%rsi), %ax
mov (%rsi), %eax
mov (%rsi), %rax

リストファイルを出してみる。

$ gcc -Wa,-a=test.lst -c -o test.o test.s

$ cat test.lst

GAS LISTING test.s page 1

   1               .file "test.s"

   2               .text

   3              

   4               .code16

   5               main16:

   6 0000 8B04     mov (%si), %ax

   7 0002 668B04   mov (%si), %eax

   8 0005 678B06   mov (%esi), %ax

   9 0008 67668B06 mov (%esi), %eax

  10              

  11               .code32

  12               main32:

  13 000c 67668B04 mov (%si), %ax

  14 0010 678B04   mov (%si), %eax

  15 0013 668B06   mov (%esi), %ax

  16 0016 8B06     mov (%esi), %eax

  17              

  18               .code64

  19               main64:

  20               // mov (%si), %ax

  21               // mov (%si), %eax

  22               // mov (%si), %rax

  23 0018 67668B06 mov (%esi), %ax

  24 001c 678B06   mov (%esi), %eax

  25 001f 67488B06 mov (%esi), %rax

  26 0023 668B06   mov (%rsi), %ax

  27 0026 8B06     mov (%rsi), %eax

  28 0028 488B06   mov (%rsi), %rax

  29              

GAS LISTING test.s page 2

DEFINED SYMBOLS

                            *ABS*:0000000000000000 test.s

              test.s:5      .text:0000000000000000 main16

              test.s:12     .text:000000000000000c main32

              test.s:19     .text:0000000000000018 main64

NO UNDEFINED SYMBOLS

ここで気が付くのは、同じ命令でも、違うコードが出ている。

例えば、

mov (%esi), %eax

は

16bitでは、67668B06

32bitでは、8B06

64bitでは、678B06

となっている。

67というのは、アドレスサイズプレフィックス

66というのは、オペランドサイズプレフィックス

これを見ると、各モードで、最も命令コードが短くなるアドレスサイズ、オペランドサイズが決まっているように見える。

16bitモードでは、アドレスサイズ、オペランドサイズが16bitが基本。

67を付けるとアドレスサイズが32bitになる。

66を付けるとオペランドサイズが32bitになる。

32bitモードでは、アドレスサイズ、オペランドサイズが32bitが基本。

67を付けるとアドレスサイズが16bitになる。

66を付けるとオペランドサイズが16bitになる。

64bitモードでは、アドレスサイズ64bit、オペランドサイズ32bitが基本。

67を付けるとアドレスサイズが16bitになる。

66を付けるとオペランドサイズが16bitになる。

48を付けるとオペランドサイズが64bitになる。

以下の表はアドレスサイズとオペランドサイズのbit幅に対し、どのようなプレフィックスを付ければいいのかを表している。


                  Mode
Addr Data   16bit 32bit 64bit

16   16      なし  6766   不可

16   32      66    67    不可
16   64      不可   不可   不可
32   16      67    66   6766
32   32     6766   なし   67
32   64      不可   不可  6748
64   16      不可   不可   66
64   32      不可   不可   なし
64   64      不可   不可   48

ハンダ用の排気ダクトを自作する

ハンダ付けを長時間やったりすると、ヤニで頭が痛くなることがありますよね。

そこで、低予算で排気ダクトを作ってみました。

材料は、コーナンで売ってるものと、ありあわせのもので作ってみました。

<<材料>>

(1) アルミダクトホース (Φ100 x 3000mm)

コーナンProで購入。698円。

(2) クーラーキャップ

コーナンProで購入。248円。

(3) アルミテープ

コーナンProで購入。598円。

(4)CPUファン

余っているものを流用。
Scythe製の NINJA3 というCPUクーラーについてた FANが余っていたので、それを使います。

(5)ACアダプタ (12V)

余っているものを流用。

(6) DCジャック
電子工作用に、秋月で買い置きしておいたものですが、流用できそうです。
秋月で100円で売っています。

<<作り方>>

ダクトホースにキャップをはめ、空気が漏れないように、しっかりとアルミテープでとめます。
キャップは必須ではないのですが、アルミダクトホースは端の部分で手を切りやすいので、安全のために、キャップを取り付けておいた方がよいです。

その上に、CPUファンを取り付けて、アルミテープでとめます。

DCジャックからピンヘッダに変換して、CPUファンへ給電しています。

完成したところ。
写真ではわかりにくいのですが、煙を勢い良く吸い込んでくれています。
NINJA3 付属のファンはボリューム付きなのが良いですね。

問題は、ダクトのもう一端をどうやって室外に出すかですが、
横から窓、上からシャッターで挟んで、外に出しています。
若干のすきま風はあります。
エアコンを入れられないので、夏と冬はつらいかも。。

奥さんに「またガラクタ増やして〜」と怒られるかと思ったら、意外にも「すごい〜」と言ってくれました。

これで快適に電子工作できますね。