RTOS以上組み込みLinux未満、Google第3のOS「Fuchsia」は大輪の花を咲かせるか：リアルタイムOS列伝（20）（3/3 ページ）

[大原雄介，MONOist]

インテルCPUでしか使えない？

　ではそのZirconカーネルを利用することでFuchsiaはどんなOSになっているのだろうか。例えばセキュリティに関していえば、以下のように、なかなか徹底的な対策が施された構成になっている。

• ZirconカーネルはCapabilityベースのオブジェクト指向型の構成になっており、デフォルトでプロセスを完全分離。リソースへのアクセスは、いちいちそのリソースへのGrant（許可）を行う必要がある。これにより、個々のプロセスのリソースアクセスが完全に管理できる
• カーネル以外の、例えばシステムサービスなどはアプリケーションと同じくソフトウェアコンポーネントとなっている。これらは独立したコンテナとして扱われ、明示的に宣言された機能のみしか利用できない
• アプリケーションソフトウェアは、自己充足型のパッケージの形で提供される。つまりアプリケーションに必要なコンポーネントなどを全て含んだコンテナとして実行されることになり、外部のパッケージとリンクしたりしない
• FuchsiaはAmbient Authority（包括的な権限）が一切存在しない。全てのコンポーネントは、自身のコンテナ内のみにアクセスできる。同様に、Global File Systemは存在せず、それぞれのプログラムには（File System操作のための）独自のLocal Namespaceが提供される

　ただ、ここまで徹底的に分離（Isolation）を施したら、OSとしてどうやって動作するのか？　という話だが、当然IPC（プロセス間通信）のスキームは用意されている。それがこちら（図7）だが、Fuchsiaではライブラリの呼び出しすらも広義のIPCとして捉えられており、FIDL（Fuchsia Interface Definition Language）を利用してこれを記述する格好である。

図7　いわゆる一般の意味でのIPCももちろんサポートはされている（これもFIDLで定義する形）［クリックで拡大］

　こういうものなので、いわゆるシステムライブラリに相当するものは一切なく、libCですら依存関係として表現されるので、ソフトウェアがそれを必要としない限り提供されないという徹底ぶりである。ただ逆にFIDLできちんと機能とデータ交換のプロトコルが一致した形で記述されていれば、あるコンポーネントを丸っきり別のものに入れ替えることも容易、というのは他のOSでは見ない特徴である（図8）。

図8　FIDLの記述例。いわゆるライブラリの呼び出し方法などをこうした形で記述する［クリックで拡大］

　ここまでいろいろ厳しいと、Fuchsiaを使ってのアプリケーション開発が結構面倒に思えるのだが、そこはGoogle。Fuchsiaは、モバイルアプリケーションフレームワークの「Flutter」によるアプリケーション開発が可能である。

　Flutterは、Android／iOS／Windows／macOS／Linuxという複数のプラットフォームに対し、ソースコードの変更なくそれぞれのプラットフォーム向けのアプリケーションを構築できるツールであり、ここにFuchsiaも含まれているというわけだ。

　さてこのFuchsia、先に紹介した記事にあるように、2019年にWebサイトが公開され、2020年12月には一般の開発者もここに参加できるようになっている。本当はその2020年12月以降の数字をお見せしたかったのだが、残念ながら資料が見つからず、2019年までの数字であるが、Commit数（図9）は月間2000回と比較的活発であり、Committerの数も次第に増えている（図10）。

図9　2018年以降はほぼ月間2000commit程度で安定している［クリックで拡大］

図10　この数字の大半はGoogle内部の開発者であり、現在どの程度外部の開発者が増えたのかは気になるところ［クリックで拡大］

　2019年の段階では、やはりGoogleの中の人による開発がメインであるが、中には100以上のCommitを行った外部の開発者もいるようだ（図11）。

図11　今後はアクティブなCommitterをどう増やしてゆくかもテーマの一つだろう［クリックで拡大］

　直近で言えば、2021年9月のFuchsia F4に加え、2022年1月にはFuchsia F4.1がリリースされたばかりである。今は、x86と64ビットArmのみがターゲット（ただし64ビットArmのサポートは“very limited and not recommended”とある）としてサポートされているが、そのx86も“AMD CPUs are not actively supported”なんてあるあたり、現時点で環境がちゃんとそろっているのはIntelのBroadwell以降のCPUと、後はFuchsiaのエミュレーターを使う（これはきちんと提供されている）しかない。

　ただ逆に言えばこれからの伸びしろがある、という言い方もできる（ちなみにAMDとIntelで何が違うのかというと、周辺のドライバのサポートということになる）。ライセンスは、ZirconカーネルがMIT License、User space componentsはBSD LicenseないしApache 2.0 Licenseでの提供になっており、必要なら商用も可能（だからこそNest Hubに実装できたわけだ）である。どちらかといえば、RTOSというよりは組み込みLinuxの代替という扱いかもしれないが、なかなか面白いOSだと思う。