間もなく登場! FreeBSD 10.0、IT技術者なら知っておくべき11の新機能

●高速圧縮アルゴリズム、圧縮キャッシュ

2年の開発期間を経て、FreeBSDの次期メジャーアップグレードバージョンとなる「FreeBSD 10.0-RELEASE」が間もなく登場する。


ほかのオペレーティングシステムでは実現されていない革新的な機能が取り込まれているほか、動作の粘り強さや適用シーンの幅の広さなどに定評があるFreeBSD。その最新版となるFreeBSD 10.0-RELEASEは、新機能や改善点がかなりの数に上り、ユーザから大きな期待が寄せられている。


本稿ではFreeBSD 10.0-RELEASEで実現される新機能の中から、特にユーザから見て注目となる11のポイントに絞って解説する。新版を活用するきっかけにしてもらえればと思う。


○ZFS機能強化とSSD対応


日本のエンタープライズやコンシューマではFreeBSDはエッジサーバに採用されることが多いが、世界のエンタープライズ市場ではFreeBSDはストレージアプライアンスやストレージシステムのオペレーティングシステムとしても広く活用されている。国内でもFreeBSDとZFSをベースにしたNASソリューションを提供している企業は少なくない。高速で堅牢に動作するUFS2+Softupdates、大規模で多機能なストレージを構築できるZFS、的確に動作するネットワークスタック、高負荷になっても粘り強く動き続けるカーネル、そしてBSDライセンスで提供されているという特徴が、NASアプライアンスやNASシステムを構築するのに適したものとなっている。


FreeBSDプロジェクトではOpenZFSやIllumos主体で開発されているZFSの機能を随時FreeBSD ZFSへバックポートしているほか、FreeBSDとしての機能追加なども実施している。FreeBSD 10.0で登場することになる主なFreeBSD ZFSの注目ポイントをいくつか紹介する。 


高速圧縮アルゴリズム LZ4

リビジョン246586のコミットではZFSに対してLZ4圧縮アルゴリズムの実装が追加された。 Illumosプロジェクトからのバックポートとなる。これはBSDライセンスで開発されたハイスピード圧縮アルゴリズムの実装で、それまでZFSが使用してきたLZJBと比較して圧縮で50%以上、展開で80%以上高速に動作するとされており、圧縮されていないデータの圧縮処理でだいたい3倍ほど従来よりも高速に動作するとされている。さらに圧縮率もLZJBよりも優れているという。


データセットを圧縮機能とともに使用している場合には処理速度の高速化と容量効率のよいストレージ活用が期待できる。


圧縮キャッシュで高速化 L2ARC Compression

ZFSはその仕組み上、安定的にまた高速に動作するのに大量のメモリを必要とする。FreeBSD ZFSであればZFS向けに使われるキャッシュ(L2ARC)はスワップ不可能なWiredなメモリ領域として確保され、ZFSストレージシステムにおける大半のメモリをここで消費することになる。


Illumosではこのキャッシュ(L2ARC)をより効率よく利用するために「L2ARC Compression」という機能を実装。251478のコミットでこの機能がFreeBSD ZFSにもバックポートされた。L2ARCの領域を圧縮して利用することで確保したメモリ領域にさらに多くのキャッシュデータを保持することで高速化を狙うという仕組みになっている。


ディスクのアクセス速度を考えると、ディスクへの入出力は極力減らした方がよい。また、最近のプロセッサのパワーを考えると圧縮・展開処理をしても、まだお釣りがくる。結果的に圧縮した方が動作が高速になる。この圧縮・展開処理には先ほど紹介した高速圧縮アルゴリズムLZ4が使われている。


上書き削除で高圧縮 NOP Writeオプティマイゼーション

FreeBSD 10 ZFSにはIllumosで開発された「NOP Write」と呼ばれる最適化機能も取り込まれている。これはデータを書き込む際に、ディスクに書き込まれているデータのチェックサムを比較して、データが同一である場合には処理をスキップしてディスクI/Oを発生させないようにするという機能。これは特にスナップショットを活用している場合にディスクスペースを節約する効果が期待できる。


「NOP Write」の実際の動作とその効果についてはリビジョン243523 zio_impl.hのコミットで追加されたコメントがわかりやすい。その特性上、重複排除(dedup)機能とは相性がよくないため、「NOP Write」機能は重複排除の機能が無効で、かつ、圧縮機能が有効になっているようなデータセットで機能する設定になっている。


ZFS TRIMのサポート

リビジョン240868のコミットでZFSにTRIMサポートが追加された。SSDのみで構成されたプールを使っている場合などに効果が期待できるとされている。TRIMサポートはUFSにはすでに追加されている。この機能はmultiplay.co.ukのスポンサーシップのもとで実施されたほか、zfsonlinuxプロジェクトの成果物からいくつか改善を取り込んでいると説明がある。


●新しいiSCSIスタック、UFSの動的拡張

○新しいiSCSIスタックの導入


FreeBSD 10にはカーネルで動作する新しいiSCSIターゲット/イニシエータの実装が追加された点も注目される。iSCSIターゲットとしてもiSCSIイニシエータとしても動作可能で、カーレベルレベルでネイティブに動作する。FreeBSDはストレージでの利用要求が高いので、そうした要望に応える形での実装になっている。FreeBSD Foundationの支援のもとで開発された成果物。


データの共有が必要であればFreeBSDにはすでにNFSが存在するが、iSCSIはそこよりも低レベルでのデータ共有を可能にする。NFSはファイルシステムレベルでのデータの共有になるが、iSCSIはブロックデバイスレベルでのデータの共有となる。iSCSIターゲットとして動作する場合にはストレージを提供する側になるし、iSCSIイニシエータとして動作する場合にはiSCSIターゲットからディスクを持ってきて利用することになる。接続したディスクは/dev/da0といった形で使えるようになり、USB HDDを接続したような感覚で使用できる。


設定ファイルの書き方や利用方法などはFreeBSDハンドブックの\28.13. iSCSI Initiator and Target Configurationにまとまっている。ZFS、iSCSI、NFS4、各種アプリケーションなどFreeBSD 10はストレージシステムのオペレーティングシステムに必要になる多くの機能がそろっている。


○UFSのオンライン growfs(8)


これまで要望が多かったUFSの動的な拡張もリビジョン243246のコミットで実施できるようになった。これまで静的にUFSファイルシステムの領域を拡張することはできたが、FreeBSD 10からは読み書き可能な状態でマウントされたUFSであっても動的にサイズを広げることが可能になる。


この機能はUFSに新しく追加された書込のサスペンド機能を使って実装されている。growfs(8)が領域を拡大し終わるまで書込処理がサスペンドされる。こうした機能は特に仮想環境での使用が想定されている。仮想ディスクイメージは固定されたサイズで提供されており、後から領域を広げたいことがある。FreeBSD 10からはgrowfs(8)を使うことでこれを実現できるようになる。


動作の高速さや消費するメモリ量の少なさなどから、仮想環境で動作する場合にはファイルシステムとしてはZFSよりもUFSの方が活用されるケースが多い予想される。オンラインでgrowfs(8)が利用できるようになることで、特にこれまでUFSで弱いとされてきた機能が補われることになる。


●BINDの排除とUnbound/LDNSの導入

○BINDの排除とUnbound/LDNSの導入


FreeBSD 10からはベースシステムからBINDが取り除かれる点に注意が必要。BINDはよくセキュリティ脆弱性が発見されるソフトウェアのひとつだが、BINDのリリースエンジニアリングとFreeBSDの相性の問題で今回ベースシステムからは外れることになった。置き換えというわけにはいかないが、これを補うことになるソフトウェアとしてUnboundとLDNSの一部がベースシステムにマージされている。


dig(1)はBINDに含まれていたツールであるため、dig(1)もベースシステムから削除されている。同じくBIND由来のhost(1)やnslookup(1)もベースシステムから取り除かれている。この代替としてはLDNSベースのdrill(1)とhost(1)が追加されている。


host(1)はDNSルックアップを実施するための簡易ユーティリティ。ちょっとした名前引きなどに利用される。


drill(1)はdig(1)をより強力にしたようなツールで、DNSおよびDNSSECのすべての情報にアクセスできる設計になっている。FreeBSD 10以降は基本的にはdrill(1)を使えばよい。


こうした新しいコマンドではなく従来のコマンドを使いたいという場合にはbind-tools(dns/bind-tools)をインストールするという方法がある。bind-tools(dns/bind-tools)をインストールするとBINDベースのdig(1)、host(1)、nslookup(1)が利用できるようになる。


Unboundはローカルキャッシュリゾルバとして導入されている。たとえば/etc/rc.confに次の設定を追加することで利用できるようになる。


次のようにUnboundを起動すると、一番最初の起動時には現在のシステムの設定から新しくUnboundの設定ファイルを生成するとともに、/etc/resolv.confファイルをunbound(8)を利用するように書き換えが行われる。ネームサーバとして127.0.0.1が指定されるようになっていればunbound(8)を利用するようになる。


実際に名前解決を測ってみるとその効果がよくわかる。たとえば次の例では、ローカルキャッシュ効果が出る前の段階ではクエリに394ミリ秒かかっている。


しかし、1度実行した後は、実行時間が1ミリ秒へ短縮していることがわかる。


Unboundでは正引きや逆引きの設定を簡単に設定することができ(/var/unbound/unbound.conf)、/etc/hostsの替わりに利用することもできる。


●次世代ハイパーバイザ/仮想環境基盤 BHyVe

○次世代ハイパーバイザ/仮想環境基盤 BHyVe


FreeBSD 10からはBSDハイパーバイザと呼ばれる機能が取り込まれている。この機能は「BHyVe」と呼ばれており、機能としてはXenやKVMに近いものになっている。XenやKVMはプロセッサが仮想化支援機能を実装する前から存在してきたためソースコードが複雑になっているが、BHyVeはプロセッサの仮想化支援機能を使うことを前提にすることで、そのあたりのソースコードがすっきりしているという特徴がある。


\10.0-RELEASEではFreeBSD 10.0-RELEASE以降のFreeBSDをBHyVeで実行することができる。現在LinuxやWindowsなどほかのオペレーティングシステムを動作させるための開発が進められており、将来的にはFreeBSD以外のオペレーティングシステムも利用できるようになる見通し。この機能ももともとストレージベンダが実装を進めていた機能だ。


たとえば次のように利用する。まず、BHyVeを実行するために必要になるカーネルモジュールの読込と、トンネルインタフェースの作成を行う。


BHyVeを直接コマンドから起動するのはオプションが多くて煩雑なので、ラッパースクリプトを利用する。次のようにNeel Natu氏が提供しているスクリプトをダウンロードしてくるとともに、FreeBSDのインストーライメージ(ISO)をダウンロードしてきて特定の名前に変換しておく。なお、2014年1月以降ならダウンロードしてくるISOファイルはRC3ではなくリリースバージョンの方がよいだろう。


ここまで準備したら、あとはラッパースクリプトに仮想マシンの名前を指定して実行すればよい。


次のようにBHyVe上でFreeBSDインストーラが起動してくる。


実行中に先ほど作成したタップインタフェースを調べると、特定のプロセス(ここではプロセス番号1162のプロセス)によってオープンされているというメッセージが確認できる。


表示されるプロセス番号を調べると、hhybe(8)というコマンドが実行されていることを確認できる。これがユーザから見えるBHyVeの本体だ。


途中で端末の種類を聞かれるのでvt100を選択しておく。


インストール作業は通常のインストール作業と同様に進めればよい。


ディスクやネットワークインタフェースはVirtIOベースのものが表示されるので、これを使用する。


インストールが完了したあとはLiveCDモードに移行して、インストールした先の/etc/ttysに次の設定を追加する。


もしここで編集せずに終了してしまった場合でも、同じディレクトリに作成される「diskdev」というファイルが仮想ディスクファイルになっているので、このファイルを直接mdconfig(8)でマウントして編集することで同じことができる。たとえば次のように作業すればよい。


再起動またはもう一度ラッパースクリプトを使ってBHyVeを実行するとディスクイメージからFreeBSDが起動してくる。


ホストから見るとBHyVeで動作しているゲストは次のようにただのプロセスに見える。確保しているメモリ領域がゲストが使用するメモリのサイズとほぼ同じになっていることも確認できる。


ゲストとして動作するFreeBSDはvirtio_pci、vtnet、vtblkのようにVirtIOを経由してデバイスにアクセスしていることがわかる。


FreeBSD 10にはVirtIO関連のデバイスドライバがデフォルトで採用されている点もポイントとなっている。このためBHyVeに限らずVirtIOがあれば動作する数々の仮想環境で実行できるようになっている。


BHyVeのひとつの活用シーンとして、ホストのFreeBSDカーネルには変更を加えずにFreeBSD Updateおよびpkg(8)による自動アップデートを実施し、カーネルの書き換えやオプションを指定してのアプリケーションが必要になるケースではBHyVe上にカスタマイズしたカーネルやソフトウェアを用意して利用するといった使い方が考えられる。ベースシステムの安定性とカスタマイズの利便性の双方を実現する方法として興味深い。


●Amazon EC2対応、Hyper-V対応、FW強化

○Amazon EC2対応


FreeBSD 10からはAmazon EC2のインスタンスが正式提供されている。Xen対応やVirtIO開発が進んだことやもあり、デフォルトカーネルの状態でAmazon EC2で動作するようになった。これはAmazon EC2上でFreeBSD UpdateベースでFreeBSDサーバを運用したり、Amazon EC2上でカーネルをカスタマイズして実行したりが簡単にできるようになったことを意味している。


リリースのタイミングでいえばFreeBSDの正式アナウンスが開始されるよりも前の段階でインスタンスは登録されており、いち早く最新版を使うことができる。Amazon EC2を利用するとハードウェアの調達などのコストをかけることなくFreeBSDインスタンスを利用することができる。これまでAmazon EC2におけるFreeBSDの利用はさほど普及していなかったが、デフォルトで利用できるようになったことで採用が進むものとみられる。


Amazon EC2ではリソースの少ないマイクロインスタンスからリソースを豊富に備えたインスタンスまで多種多様なコンピュータリソースが提供されており、一定期間だけECサイトを展開したいとか広告を出したい、動画配信をしたい、HPCを実施したいなどの用途に柔軟に対応できる。


○Hyper-V仮想化プラットフォーム


仮想化プラットフォームへの対応という点でみると、MicrosoftのHyper-V対応がデフォルトで追加された点もFreeBSD 10の特徴になっている。MicrosoftとCitrix、NetAppが共同で作業を進めた結果、FreeBSD向けのHyper-Vインテグレーションサービスの実装がオープンソースで公開されることになり、この成果物がマージされた。


FreeBSD 10.0は次のようにHyper-Vとのサービス統合が実現されている。


・Hyper-Vコンソールからのシャットダウンの実施

・Hyper-VホストとFreeBSDゲストの間での時刻同期の実施

・Hyper-V特有のIDEストレージデバイスおよびSCSIストレージデバイスに対応

・Hyper-V特有のネットワークアダプタに対応

・特定のIPアドレスを使わなくともライブマイグレーションを実現


Hyper-VでFreeBSDを運用する場合はFreeBSD and Microsoft Windows Server Hyper-V supportのページに情報がまとまっているので参考にしておきたい。


○ファイアウォールipfw(8)機能強化とpf(4)マルチコア対応


FreeBSD 10のファイアウォールであるipfw(8)にはIPヘッダのDSCP(DiffServコードポイント)に対する設定または一致の機能が追加された。IPv4およびIPv6の双方に対応。DSCPの値は名前ベースでも数値ベースでも指定でき、一度に複数のクラスを指定できる。


FreeBSDにおいてもっとも開発が進んでいるファイアウォールがipfw(8)だ。FreeBSDでファイアウォールを使う場合はipfw(8)を選択するものだと考えておいて問題ない。ipfw(8)はマルチコア/メニーコアにおいて性能が発揮できるようによく開発が進められており、動作も軽快。


一方、OpenBSDで開発されたpf(4)もFreeBSDでは人気がある。pf(4)はフィルタルールの記述がわかりやすく強力な指定を記述できる。FreeBSD 10のpf(4)はさらにマルチコアへの対応も進められ、従来のバージョンよりも性能が発揮できるようになっている。


ただし、FreeBSDのpf(4)を使う場合にはいくつか検討した方がよい点がある。まず、性能の面ではipfw(8)の方が優れていること、ロバスト性の面でもipfw(8)がよいと見られていることだ。仮想環境で動作させた場合もipfw(8)の方が堅牢に動作する傾向がある。pf(4)を採用する場合には高負荷時にpf(4)がちゃんと動作するか検証した上で採用した方がよいといえる。


●デフォルトコンパイラ変更、マルチ/メニーコア対応、高速通信機能

○デフォルトコンパイラをGCCからLLVM Clangへ


FreeBSD 10.0からはデフォルトのコンパイラが従来のGCCからLLVM Clangへ置き換わっている。FreeBSDプロジェクトはGPLv3のソフトウェアをベースシステムにマージしない方針をとっているため、これまではGPLv3にライセンスが変更される以前のGCC 4.2.1を使い続けてきた。古いコンパイラで、さまざまな面で最新の状況への対応が難しくなっていた。


そこでFreeBSDプロジェクトはコンパイラインフラストラクチャとしてLLVM Clangの採用を決定した。LLVM ClangはBSDライセンスで開発されており、開発も活発、LLVM ClangのコミュニティとFreeBSD開発者のコミュニケーションも円滑に進んでいる。さらにGCCと比較してコンパイル時間がとても短いという特徴がある。ビルドを繰り返すソフトウェアのプロジェクトにあってはソフトウェアのビルド時間が短いことは大きなアドバンテージになる。


FreeBSDに限らず、同様の理由でGCCからLLVM Clangへ移行したプロジェクトはいくつもある。Linuxでもコンパイル時間の短さなどを理由にLLVM Clangでビルドできるようにする取り組みが行われている。


LLVM Clangが出力するエラーメッセージはGCCのエラーメッセージと比較して理解しやすいという点も開発者に好まれる一因になっている。GCCのエラーメッセージでは原因が掴みにくいものでも、LLVM Clangでビルドするとエラー部分が理解できることが多い。開発のみならず教育向けのコンパイラとしても利用できる。


○マルチコア/メニーコアで性能向上させる Unmapped VMIOバッファ


FreeBSD 10は従来のバージョンよりも大規模なマルチコア/メニーコアの性能が発揮できるようになっている。これはJeff Roberson氏およびKonstantin Belousov氏が開発した「Unmapped VMIOバッファ」という機能が理由になっている。FreeBSDカーネルは大規模なマルチコア/メニーコアのシステムに対してまだ性能を引き上げる余地があるとされており、「Unmapped VMIOバッファ」はそうした取り組みのひとつ。


VMIOバッファの作成と削除のタイミングですべてのコアに対してTLBの無効化の操作が実施されているが、この部分が性能のひとつのボトルネックになっている。この処理のなかでデータのコピーが発生するもののまったく使われることなく破棄されているものがある。「Unmapped VMIOバッファ」はこうした無駄な処理を実施しないようにする機能。この機能が取り込まれたことでいくつかの作業が高速化している。


○高速ネットワーク通信機能 NetMap


動画配信やビックデータ処理(大量のログデータの処理、遺伝子情報解析、天文台データ処理、統計データ処理など用途はさまざま)、ネットワークの基幹部分の通信などではより高速な通信が求められており、10GbEや40GbEといったより高速なネットワーク通信が求められている。こうした高速通信のデバイスをより効率的に利用するための機能「NetMap」が統合されている点もFreeBSD 10のひとつの特徴といえる。


NetMapの機能は10GbEのみならず1000baseTのNICでも効果が期待できる。ハードウェア的にはNetMapを活用することでネットワームモニタやソフトウェアスイッチなどを開発しやすくなるという特徴がある。ネットワークを流れるパケットを取得して高速に解析する必要があるようなアプライアンスの開発に利用できる。


高速通信という面では費用対効果的にもInfiniBandに人気があるが、InfiniBandはドライバの提供されているオペレーティングシステムが限られており、さまざまな種類のノードが混在するような環境では使いにくい面がある。一方、10GbEや40GbEといったネットワークは利用できるオペレーティングシステムも多く、従来の技術の延長でシステムが構築できるという利点がある。


(後藤大地)

Intel Galileoを試す - 超小型SoC「Quark X1000」搭載のArduino互換ボード

●Galileoファーストインプレッション

既報の通り、Intelは10月3日にGalileoボードを発表すると共に、ソフトウェアやドキュメントの配布を開始した。さて、そのGalileoボード、11月に国内販売計画が発表されたものの、後追いで1月中旬の発売に延期される( インテル-galileo-開発ボード-発売延期のお知らせ )といった騒ぎになっている。

【もっとほかの写真をみる】

この発売延期、実は国内だけの話ではない。実は筆者は、香港のMouser Electronics(www.mouser.com)でGalileoの扱いが始まった10月17日に早速申し込んでおり、その際の推定出荷時期が11月13日だったのが、その後12月2日、12月13日とどんどんずれてゆき、12月17日に一旦出荷時期未定に切り替わった後で、やっと12月24日に出荷された(Photo01)(この原稿を書いている12月26日時点では、江東区まで届いており、現在税関の処理待ちの模様)。10月にオーダーしたものがこれだから、一般に広く流通するにはまだ大分掛かりそうである。


さてそんなGalileoであるが、幸いIntelより評価ボードを借用する事が出来た。とはいえ、つい最近も某社から拝借した開発ボードを2枚も"燃やした"経験があるので、自分のボードが入手できるまでは余り「攻めた」レビューは怖くて出来ない。そんなわけで今回は、とりあえずの感触ということでファーストインプレッションをお届けしたい。


○相変わらず鳴り響くIntelサウンド


さてGalileoボードはこんなパッケージに入って届けられる(Photo02,03)。パッケージの中身はボード本体とACアダプタ、MicroUSBケーブル、Quick Stard Guideとなぜかバニー人形が入っていた(Photo04)。ちなみにパッケージを開けただけでは何も起きないが、ACアダプタなどを取り出すべく中の仕切りを外すとお馴染みIntelサウンドが。仕切りの裏にオルゴールが実装されていた(Photo05)。


さて、ボードそのものは以前の写真と殆ど同じである(Photo06)。裏面はこんな具合。ちなみにACアダプタは3.1A出力のものが付属してきており、微妙に裏面のシールの表記とあっていなかった。ボードサイズは実測で102mm×73mmで結構大きい。比較のために手持ちのArduino UNO/Arduino MEGAと並べたのがこちら(Photo08)で、長さはほぼMEGAと同程度だが、幅は明らかに一回り大きい。もう一つ問題になるのが高さ方向。水平に置くと、Mini PCIeコネクタ(Photo09)及びMini PCIeカードホルダー(Photo10)で高さが保持されている形だが、Mini PCIeコネクタはともかくカードホルダーの方は明らかに強度不足である。Photo04では隠れてしまっているが、28mmのスペーサーと取り付けネジが4対付属しているのは、このコネクタやカードホルダーに力がかからないようにスペーサーで基板を浮かせろ、という意味だと思われる。


あと個人的感想だが、Quark X1000チップがダイむき出しになっており、Shieldの着脱にうっかり何かぶつけただけでダイが削れそうなのは怖い。正直開発キットとして使うには脆弱な気がする。昔のICHの様なプラスチックパッケージにするか、薄いアルミ板でいいからヒートシンク兼用でカバーを用意してほしかったところだ。


●色々癖のあるソフトウェア環境

○色々癖のあるソフトウェア環境


さて、では使う手順である。Galileoの場合、Arduino互換のソフトウェア環境と、それとは別にLinux BSP(Board Support Package)も提供され、どちらでも利用可能となっているが、筆者は当然マイコンボードとしてのGalileoに興味があるので、Arduino互換環境を構築してみた。さて、ソフトウェアであるがIntel Makers Communityから入手できる。筆者の場合はWindows 7の環境なので、"Intel Galileo Arduino SW 1.5.3 on Windows"をダウンロードする。で、これはzipファイルなので展開するのだが、この際に展開先を"C:\"にする必要がある。実際は別の場所でもいいのだが、C:\Program FilesとかC:\Program Files(x86)ではダメである(理由は後述する)。また、同時にGetting Stated Guideも入手しておこう。


次にUSBのドライバのインストールである。手順だが、


1. GalileoボードにACアダプタを接続して電源On(GalileoはUSB Bus Powerでは動作しない。Getting Started Guideによれば「ACアダプタを挿さずにUSBを接続するとボードが壊れる可能性がある」と警告されている)。

2. USBケーブルを、GalileoのUSB Client側コネクタ(Photo06で中央上の左側)に接続し、PCとつなげる。

3. Device ManagerでGadget Serial Driverが出現するのを確認し、これの「ドライバの更新」を行う(Photo11)。

4. Driverの指定で、hardware\arduino\x86\tools を指定する(Photo12)。

5. ドライバが認識されて、正常にCOMデバイスとして登録される(Photo13〜15)


ここまで終わればあとはC:\Arduinoにあるarduino.exeを起動するだけで良い(Photo16)。ところで先ほど説明した"C:\"以外では駄目な理由をちょっと説明したい。とりあえずLチカということでList 1の様なSketchを入力してみる。これを例えばC:\Program Files(x86)の下に置いたArduinoでビルドしようとすると、こんなエラーになる(Photo17)。要するに、Arduino IDEからg++を呼び出すにあたり、ロングファイルネームに対応してないのだ。だから、別にC:\でなくてもロングファイルネームで正しく扱えるディレクトリならばビルドは問題なく可能である。実際 C:\Galileo というディレクトリを作成し、ここにインストールしても問題なくビルドが可能だった。ということでインストールの際には注意されたい。


■ List 1


●プログラムはNativeで実行

○プログラムはNativeで実行


さて、気を取り直して先ほどのList1のLチカを実行。Pin 13とGNDの間にLEDを繋いで動作させてみた。Sketch Sizeは49,046 Bytesで全体の18%(最大262,144Bytes)となる。内部はスクリプトが色々動いているようで、Arduino IDEのステータス欄に色々動作状態が出てくる(Photo18)。


で、肝心の動作は? というと、最初ACを繋いだ状態だとLEDが微妙に点灯しているだけ(Photo19)だが、Sketchをロードするとちゃんと1秒間隔で点滅を繰り返す(Photo20)。で、USBケーブルを抜いても問題なく動作は継続する(Photo21)。問題はここで一度ACアダプタを抜いて、再度ACアダプタを接続した場合。Arduinoの場合だと、SketchはFlash Memoryに格納されるから、電源を入れればPower on bootでFlashからSketchが読み出され、再び勝手に実行を始める。ところがGalileoの場合はPhoto19の状態に戻ってしまうのだ。つまりGalileoのArduino互換モードでは、SketchはFlash MemoryではなくSRAMに格納されるようだ。先にSketchの最大サイズが256KBと書いたが、おそらくSRAMの半分をSystemで、残りをSketchで利用しているのだろう。


このあたりでArduino互換とは言え、使い方にちょっと制約が出てくる気がするが、それはさておきファイルサイズの話。同じSketchをArduino UNO用にビルドすると1,076Bytesである。アーキテクチャが違うとはいえ、何でここまでファイルサイズが違うのか? ということで、ちょっとバイナリを確認してみることにした。


Galileo向けのArduino IDEでは最終的にELFフォーマットでバイナリを生成するようだ。先のPhoto18にもちょっと出てくるが、Galileo用Arduino IDEは自動でユーザーディレクトリの下の方(詳しくはPhoto18を参照)にディレクトリを作り、その中にファイルを生成する(Photo22)。で、この中にある.elfファイルがGalileoにダウンロードされるものの様だ。そこでobjdumpを使って中身をちょっと確認してみた。まずobjdump -xでヘッダ情報を出したのがList 2である。ファイルフォーマットはelf32-i386なので、つまりこのSketchはGalileoでNativeで実行できるようになっていると考えられる。


■ List 2


んではobjdump -dでディスアセンブルするとどうなるか、をリスト全部掲載すると長すぎるので抜粋をList 3に。.initはもうファームウェアの初期化ルーチンを呼んでるだけだし、.pltは処理テーブルがひたすら並んでいるだけである。で、こまごましたものは.textに全部突っ込んであるが、明らかに今回の処理と無関係な関数のディスパッチルーチンまで含まれており、このあたりが無駄に突っ込まれている結果としてファイルサイズはかなり大きくなっていると考えられる(ちなみにobjdumpで -Sオプションをつけてもソースは表示されなかったので、g++でデバッグオプションは付加されていない模様)。


■ List 3


ただし、この結果として性能は猛烈に高い。以前chipKit32を比較したときのSketch(List 4)をそのまま実施してみたところ、


だった(以前Arduino Unoでは約11秒だったので大分遅くなってるのだが、Arduino IDEのバージョンが大分違うので、おそらくこれが影響しているのではないかと思う。ちなみに今回は1.0.5を利用)。これは81億回の足し算を500回繰り返すものだが、性能面では勝負にならないほどGalileoが高速だった。まぁ16MHz駆動の8bit MCUと400MHz駆動のPentium互換CPUで性能が同じでは話にならないので当然ではあるが、とりあえずArduino IDEで記述したSketchは、仮想マシンなどで動くのではない様である。まぁこれはこれで、ループなどでタイミング調整を行っているSketchでは問題が出てくるかもしれないが。


■ List 4


●互換性その他気がついたところ

○互換性その他気がついたところ


さて、一応Lチカが動いたところで、昔のArduino用の自作ShieldやSketchを動かしてみたところ、割といい感じで全滅した。というのは筆者の場合、PCと連携して何かの表示を行うようなSketchを自作するのがメインで、この際にPCとArduinoの間を仮想COMポート経由で通信する仕組みにしているのだが、Galileoだとこれがうまく動かなかった。おそらくはPhoto13に出てくるDCSG Validation Toolsの仕様が、Arduino Unoとかその前のArduino Duemilanoveで搭載されていたUSB-UART用ドライバと異なっているのだろう。プログラム的に見ると、COMポート(筆者の環境で言えばCOM18)をCreateFile()で開く事は出来るのだが、その後でGetCommState()で状態の取得をしようとしてコケている感じである。なので厳密に言えばGalileoの問題というよりはWindows用ドライバの問題なのであるが、そんな訳で手持ちのShieldの確認は今のところ出来ずじまいである。


あともう一つ気がついたのは、恐ろしくGalileoの発熱が多い事。普通、この手のマイコン開発ボードが熱くなる事は無い(というか、ありえない)のだが、Galileoはカイロの代わりになりそうな程度に熱い。まぁACアダプタが5V2A供給で10Wだから、これがフルに消費されているとすれば熱いのも当然ではある。発熱箇所は基板表と裏にある電源レギュレータ周りの部品(Photo06で、Quark X1000のすぐ左にあるやつ。中身はインダクタンス)で、これが表に2つ、裏に1つ搭載されているから熱いのも無理はない。ついでに言えばQuark X1000自体も触れないほど熱くなる。理由はなんとなくわかる、というかGalileoの場合、I/OデバイスをSoC内部で完結させきれず、I2Cなど経由でボード上に実装しているし、他にFlashだDDR3だと部品が色々乗っているから、こうしたもののために電源レギュレータが必要で、これによる発熱が馬鹿にならないのだろう。なるほどUSB Bus Powerでは動作しないのも無理ないし、仮にACアダプタを使わずにUSBを接続すると破壊されても不思議ではない。


なんというか、作りなれていない構造だなぁ、というのが率直な感想である。


○ということで


まずは簡単にファーストインプレッションをお届けした。ちなみに今回はBSPを使ってLinuxをブートする方は一切試していない。また電源Onからの自動Sketch実行も、もしかするとSD Cardを使えば可能かもしれない(マニュアルにそれらしき記述はある)が、これもまだ未テストである。


なんというか、いわゆるMCUベンダーの評価ボードのつもりで使うとあっという間に壊れそうな脆弱さを感じる部分はあるが、とりあえずちゃんと動く事が確認されたのは喜ばしい。USB周りについては、もう一つUARTが実装されているのでこちらを使っての接続とかも今後試してみたいと思う。


(大原雄介)

Ruby 2.1.0登場

12月25日、Rubyの最新版となる「Ruby 2.1.0」が公開された。ひとつ前のバージョンと高い互換性を実現しつつ、パフォーマンスの向上が実現されている。「Ruby 2.1.0」以降はセマンティックバージョニングに沿ったバージョニングへ移行することになっている。「MAJER.MINOR.TEENY-PATCH」という形式となり、それぞれ次のようなルールに則って番号の変更が行われることになるものとみられる。


・MAJOR:リリースでは対応できない非互換性をともなう変更がある場合に増加

・MINOR:APIレベルで非互換が発生する可能性した場合に増加。およびクリスマスに増加

・TEENY:セキュリティ修正やバグ修正のリリース(API互換性あり)

・PATCH:MINORリリースからのコミット数(MINOR更新時に0へリセット)


「Ruby 2.1.0」のソースコードはダウンロードのページから取得できるほか、LinuxやFreeBSD系のディストリビューションではそれぞれのパッケージ管理システム経由でインストールできるようになるものとみられる。


(後藤大地)
おすすめ
記事検索
  • ライブドアブログ