Apache NuttX：POSIX/ANSI準拠RTOSと端末シミュレータ

POSIXとfork()を避けるNuttXの境界

Apache NuttXのREADMEは、標準準拠と小さなフットプリントを優先するリアルタイムOSだと定義する。主に従うのはPOSIXとANSIで、それらに無い機能、あるいは深く組み込んだ環境に向かない機能については、Unixや他のRTOS（例としてVxWorks）のAPIを取り込む、と書く。fork()は、深い組込みに適さない標準APIの例として本文が名指しする。POSIX準拠を掲げつつ、forkを機械的に移植しない、という境界が最初に読める。

文書の多くの箇所ではApache NuttXを単にNuttXと呼ぶ、とREADMEが断っている。実装言語はC、ライセンスメタデータはApache-2.0、既定ブランチはmaster、公式サイトはnuttx.apache.org。素材時点でアーカイブではない。pushedAtとreleasesはこの素材では空である。README上部バッジはライセンス頁、contributors、GitHub Actionsのbuild.yml、文書トップ、membrowse.com/public/apache/nuttxを指す。

fork()を外す判断は、MMUの無いMCUや、プロセスモデルを載せない構成を想定している、と読むのが本文に近い。POSIXファイルAPIやスレッドAPIまで全部が同じ密度で実装されているかは、READMEは書いていない。Getting Startedへ進む前に、自前コードがfork、exec、動的プロセス生成のどれに依存するかを切り分けた方が早い。依存が深いなら、NuttXの「POSIX寄り」は期待とずれる。

8ビットから64ビットまでの拡張範囲

READMEは、NuttXが8ビットから64ビットのマイクロコントローラ環境まで拡張できる、と書く。特定のボード名は本文に無く、一覧はSupported Platforms頁（nuttx.apache.org/docs/latest/platforms/index.html）へ送られる。8ビットと64ビットを同じソースツリーで扱う、という主張は、ボードサポートパッケージの厚みが機種ごとに違う可能性を隠さない。READMEはベンダー別の分類も、フラッシュ容量の下限も書いていない。

言語がCであることは、アセンブリ必須の極小環境というより、CでPOSIX風に書けることを優先している、と位置づけられる。VxWorks由来APIを足す、という一文は、POSIXだけでは足りないドライバやメッセージキュー相当を、別系の名前で用意している可能性を示す。どのヘッダがVxWorks互換なのかはREADME本文の外である。

スケールの話を、性能の話と混同しない。8ビットで動くことと、そのチップで自前の制御周期が守れることは別である。READMEはサイクル数、レイテンシ、ROM/RAMの典型値を出していない。対象MCUがplatforms頁に載っていることと、自前の周期処理がシミュレータで再現できること、この二つを分けて確認する必要がある。

quickstartシミュレータがボード無しの入口

Getting Started節は、初めてならnuttx.apache.org/docs/latest/quickstart/index.htmlを読め、と案内する。ボードが無くても、NuttXは端末上で動く独自シミュレータを持つ、とREADMEが書く。ビルドコマンド、起動コマンド、ホストOSの前提はREADME本文に無い。シミュレータは「ボード無しで試す入口」であり、実チップのタイマ精度や周辺の電気的挙動を保証する、とは書いていない。

シミュレータが動いたあとに実ボードへ移る手順も、README本文には無い。platforms頁でボードを確認し、quickstart側のボード固有手順を追う、という二段になる。READMEはサポート対象のターゲットアーキテクチャ一覧を本文に載せず、ページへ委譲している。自社ボードがリストに無い場合、移植コストはContributingガイドのワークフローを読む話になる。

端末シミュレータは、POSIX APIの呼び出しがリンクできるか、設定の切り方が分かるか、を見る用途に向く。ADCや独自バスのタイミング検証には、README上は実ボードか、platforms頁が示すそのチップの記述が要る。quickstartを読まずに、GitHubのCソースだけをgrepして「動く」と判断するのは、READMEが示す順路ではない。

docs/latestとwikiとローカル文書ビルド

現行文書はnuttx.apache.org/docs/latest/ のDocumentation Page。自分でビルドする場合はnuttx.apache.org/docs/latest/contributing/documentation.html。旧文書はApache wiki（cwiki.apache.org/NUTTX/NuttX）に残る。READMEは三者の優先順位、wikiをいつ使うべきか、を書いていない。まずdocs/latestを正本とみなし、欠けている歴史的記述だけwikiを当たる、という運用が無難である。

文書をローカルビルドする手順は、コントリビュータ向けである。アプリ開発者がquickstartを試すだけなら、公開HTMLで足りる。READMEは文書ビルドの依存ツールや所要時間を本文に書いていない。Instructions頁を開く前に、今読みたいのがAPIなのかボードなのかを決めた方が、wikiとlatestを往復しなくて済む。

membrowse.com/public/apache/nuttxのバッジはコード閲覧用の外部入口で、公式文書の代替ではない。GitHub Actionsのbuild.ymlバッジはCIの存在を示すが、どのボードをビルドマトリクスに入れているかはREADME本文に無い。文書の正本はdocs/latest、ボードの正本はplatforms頁、CIの中身はbuild.yml、と分けて開く。

platforms/index.htmlでMCUを照合する

Supported Boards節は、幅広いプラットフォームをサポートするとだけ書き、ボード名を列挙しない。正式な一覧はnuttx.apache.org/docs/latest/platforms/index.html。特定のMCUが使えるかは、READMEだけでは答えられない。アーキテクチャやベンダーの切り方も、そのページ側の話である。

自社で使うチップ名でplatforms頁を検索し、載っていなければ、NuttXの「8から64ビット」という一文を根拠に採用しない。載っていても、周辺ドライバの完成度はREADMEの範囲外である。シミュレータでPOSIX APIを試した成功を、未掲載チップへの移植見込みと足してはいけない。

一覧が広いことは、サポートの深さの証明ではない。READMEはボードごとの保守担当、リリース周期、長期ブランチを書いていない。素材にreleasesが無いので、安定タグをREADMEから選ぶこともできない。版を固定するなら、ドキュメント頁が示す手順と、リポジトリのmaster以外のタグ有無を、自分でGitHub Releasesページから確認する必要がある。

contributingガイドのGitとコーディング標準

Contributing節は、nuttx.apache.org/docs/latest/contributing/index.htmlを読めとだけ書く。中身の要約としてREADMEが挙げるのは、Gitの使い方、コーディング標準、ワークフロー、NuttXの原則、である。原則の本文はREADMEに無い。パッチを送る前にガイドを開く、というのがこの節の実質である。

文書ビルド手順（contributing/documentation.html）と貢献ガイドは別URLである。ボード移植と文書修正では、見るページが違う。GitHubのissue運用、ラベル、テンプレートはREADMEに無く、ガイド側の話になる。build.ymlが何を検査するかも本文外なので、ローカルで通したつもりがCIで落ちる、というずれは、Actionsのワークフローを開くまで分からない。

コーディング標準が厳しいRTOSでは、自前ドライバのスタイルを先に合わせないとレビューで戻る。NuttX principlesが何を禁じるかはガイドを読むまで不明、と明記しておく。READMEだけで「貢献しやすい」とは言えない。

Apache 2または互換ライセンスの二重表記

License節は、このリポジトリのコードがApache 2ライセンス、またはApache 2と互換のライセンスの下にある、と書く。詳細はnuttx.apache.org/docs/latest/introduction/licensing.html。全部が単一のApache-2.0ファイルではない、というのが本文のポイントである。サードパーティ由来で互換ライセンスのまま残っているソースがある、と読むべきである。

メタデータのSPDXはApache-2.0でも、再配布前にlicensing頁とリポジトリ内のLICENSE、各ファイルのヘッダを当たる必要がある。READMEは保証、サポート、特許訴訟時の扱いを本文に展開していない。組み込み製品へ入れる場合のNOTICE掲示も、licensing頁側の確認になる。

互換ライセンス混在は、静的リンクして単一ファームを出す現場では、ライセンス監査の工数が単一Apache-2.0より増える。READMEが「or a license compatible with the Apache 2 license」と書いた理由を、licensing頁でファイル単位に落とさないまま量産に入れるのは、この節の読み方として粗い。

simulator起動後にplatformsでチップを確認する

評価の第一段は、nuttx.apache.org/docs/latest/quickstart/index.htmlに従い、READMEが案内するシミュレータを端末で起動できるかを見ることである。起動コマンドはREADME本文に無いので、QuickStart側の手順が正本になる。第二段でnuttx.apache.org/docs/latest/platforms/index.htmlを開き、使うMCUやボードが載っているかを照合する。

fork()を深い組込みに向かない例として挙げる一文は、プロセスモデル前提のミドルウェアをそのまま持ち込めない合図である。POSIX風に書けても、Unixユーザー空間アプリケーションを無改変で載せる、という意味ではない。性能、セキュリティモデル、機能安全認証はREADME本文外である。

向くのは、POSIX/ANSI寄りのC APIで、8から64ビットの範囲のMCUをまたぎたい組込みチームが、まずシミュレータとplatforms一覧で可否を切る場合。向かないのは、fork/exec前提のコードを移植したい場合、認証書がREADMEから欲しい場合、対象ボードがplatforms頁に無いのに「広いサポート」だけを根拠にする場合である。

編集部の結論

POSIX寄りのAPIで8から64ビットMCUまで一つのRTOSを評価したい組込み開発者向け。実ボードが無いならnuttx.apache.org/docs/latest/quickstart/index.htmlのシミュレータから入り、対象MCUはdocs/latest/platforms/index.htmlで照合する。READMEは性能数値、セキュリティモデル、規制認証を書いていない。医療や自動車の認証が先に要る案件には、このREADMEだけでは足りない。

公式情報源

1. Official documentation
2. Official README
3. Project repository