おそらくYoctoは必要ないし、それで問題ない

 (sigma-star.at)
1 ポイント 投稿者 GN⁺ 21 시간 전 | 1件のコメント | WhatsAppで共有
  • Yoctoはディストリビューションではなく、独自のLinuxディストリビューションを組み立てるためのツールであり、そこまでの制御が不要ならデフォルトの選択肢にしにくい
  • 独自ディストリビューションは自前メンテナンスを意味し、CRAのような規制や製品寿命中のセキュリティアップデート責任も伴う
  • Yoctoの導入には、数時間のビルド、100GiB超のビルドディレクトリ、数週間の学習コスト、品質にばらつきのあるBSPレイヤーが含まれる
  • アプリケーション実行用の堅牢なLinux基盤が必要なだけなら、Debianとmkosi・ELBE・debosのようなイメージツールで、はるかに少ないプロジェクト固有の作業で十分な場合がある
  • 強いカスタマイズ性、サイズ・起動時間の制約、ライセンス除外、堅牢なベンダーYoctoサポートがある場合にだけYoctoが優位であり、迷うなら既存ディストリビューションのほうがよい

Yoctoの実際の性格と、なぜデフォルトの選択肢になりがちなのか

  • Yoctoは「Yocto Linuxディストリビューション」ではなく、独自のLinuxディストリビューションを作るためのツール群である
  • Yocto Projectはbitbake、openembedded-core、meta-yoctoで作られたリファレンスディストリビューションPokyをあわせて提供している
  • Yoctoは、組み込みプロジェクトに必要なLinuxシステムを細かく組み立てられるようにする
    • ユーザー空間全体を対象CPU向けにコンパイルできる
    • どのコンポーネントにもパッチを適用できる
    • 各レシピの機能を有効・無効にできる
    • すべてのバージョンを固定または変更できる
  • 多くのSoCベンダーやハードウェアパートナーが、そのまま使えるBSP(Board Support Package)レイヤーを提供しており、実機で動作する出発点を用意してくれる
  • 柔軟性とベンダーサポートの組み合わせによってYoctoはデフォルトの選択肢になりやすいが、そこまでの制御が必要でないなら、その分だけ負担が大きくなりうる

独自ディストリビューションは自前メンテナンスを意味する

  • **Cyber Resilience Act(CRA)**のような規制は、製品提供者に対し、配布したソフトウェアを安全に維持し、製品寿命のあいだセキュリティアップデートを提供することを求める
  • 一般的なYoctoリリースの保守期間は、次のリリースが出るまでの約7カ月にすぎない
  • Yocto 5.0 Scarthgap以降、現行ポリシーではLTSリリースは最長4年のアップデートを受ける
  • Yoctoリリースは、特定バージョンとメタデータを持つbitbakeレシピ群、およびリファレンスディストリビューションPokyで構成される
  • 保守期間中、YoctoのメンテナーはコンポーネントとPokyにバグ修正とセキュリティ修正を適用し、ソフトウェアコンポーネントの修正は通常、最新のupstream版からバックポートされる
  • 実際の製品では、Yoctoをそのまま使うより、次のような変更が入りやすい
    • 一部コンポーネントに単純ではないパッチやローカル変更を適用する
    • Yoctoが提供しない追加コンポーネントを含める
    • 修正を受け取るため、あるいは既知の良好状態を保つためにバージョンを更新または固定する
  • Yoctoのメンテナンスリリースが出るたびに、ローカル変更が新しい状態の上にきれいに適用されるか確認しなければならない
  • 追加した、あるいは固定したコンポーネントはYoctoメンテナーには把握できないため、それらが継続して修正を受けているかも自分で確認する必要がある
  • Pokyをほとんど変更せずに使っているなら、そもそもYoctoが本当に必要なのかを見直すべきである

Linuxカーネルとベンダー依存

  • Yoctoは各リリースの一部としてLinuxカーネルを提供・保守するが、実製品でそれを無改変のまま使うことはまれである
  • 通常は少なくともベンダーパッチを適用する必要があり、必要なドライバーと修正を含む十分に新しいカーネルを使うべきである
  • CVE追跡まで含めると、カーネルだけでもYoctoを使うかどうかに関係なく大きな保守負担になる
  • 保守負担を制御するには、kernel.orgのLTSカーネルを基盤にし、すべての変更を整理されたパッチキューとして維持する方法が推奨される
  • セキュリティ修正を追うには、新しいstableリリースへ移り、そのうえでパッチキューを再適用する
  • kernel.orgはLTSカーネルを数年にわたって保守するため、通常はパッチキューがきれいに適用され、実質的な作業が必要なのは新しいLTSリリースへ移るときだけである
  • 設定やセキュリティ要件によっては、ブートローダーにも同じ原則が当てはまり、ブートローダーもまたベンダー固有要素が大きいのが普通である
  • ベンダー提供カーネルをそのまま維持するやり方は、たいてい望ましくない
    • vendor kernelはkernel.orgより何年も遅れていることが多い
    • ほとんどアップデートを受けない
    • 大半のセキュリティ修正を取り逃す

Yocto導入コスト

  • 独自ディストリビューションを作るという選択は、実際のエンジニアリング時間を必要とする

  • ビルド時間

    • Yoctoは事実上あらゆるものをソースからコンパイルする
    • それほど複雑でないレベルを超えるイメージでも、クリーンビルドには高速なワークステーションで数時間かかる
    • sstate-cacheと共有DL_DIRは反復ビルドを速くするが、小さなレシピ変更だけでキャッシュの大部分が無効化されることもある

  • ディスクとCIコスト

    • Yoctoのビルドディレクトリは簡単に100GiB超まで膨らむ
    • CIランナーには十分なストレージと、ジョブ間でsstateを共有する仕組みが必要になる
    • sstateとDL_DIRをミラーすれば苦痛は減るが、そのインフラは自分で運用しなければならない

  • 学習コスト

    • bitbakeレシピ、レイヤー、動的レイヤー、クラス、オーバーライド、bbappendファイル、PACKAGECONFIG、DEPENDSとRDEPENDSの違いなど、習得すべき項目が多い
    • エンジニアがYoctoコードベースにオンボーディングされるまでには、数日ではなく数週間かかる

  • BSPレイヤーの品質のばらつき

    • 一部のSoCベンダーは、きれいでよく保守されたBSPレイヤーを提供する
    • 一方で、5年前のカーネルやブートローダーを固定し、マシン固有レシピを誤ったレイヤーにハードコードし、Pokyを上げるたびに壊れるmeta-vendorレイヤーを提供するベンダーもある
    • 良い出発点に見えるBSPが、ビルドで最悪の部分になりうる
    • こうした要素はYoctoを避ける理由ではなく、導入前に本当に必要かを確認すべき理由である

代替案: 実績あるディストリビューションの再利用

  • アプリケーションを実行する堅牢なLinux基盤だけが必要なら、Debian GNU/Linuxのような既存ディストリビューションで、同じ問題の大部分をはるかに少ないプロジェクト固有作業で解決できる
  • Debianは現在およそ70,000個のバイナリパッケージを提供している
  • 対応アーキテクチャにはamd64、i386、arm64、armhf、riscv64、ppc64elなどが含まれる
  • 多くのSoCでは、再コンパイルなしでDebianバイナリをそのまま実行できる可能性が高い
  • Debianはsystemd、udev、dbusを含むモダンなユーザー空間だけを提供するディストリビューションではない
  • アーカイブには、SysVスタイルinitやBusyBoxベースの小さなLinuxシステムを作るための要素も含まれている
  • 薄い基盤を選び、製品に必要なパッケージだけをインストールしつつ、Debianパッケージメンテナーの作業を活用できる

Debianの保守モデル

  • Debian stableはDebian Security Teamから約3年セキュリティアップデートを受ける
  • その後、コミュニティベースのDebian LTSプロジェクトが一般的なアーキテクチャでさらに約2年サポートを延長する
  • 実質的に1リリースあたり約5年のサポートが可能で、Yocto LTSに近い水準だが、プロジェクト固有の作業ははるかに少ない
  • 最新の修正を取り込むには、最新のDebianパッケージを取得してイメージを再作成すればよい
  • Yoctoでupstreamパッチを自分でバックポートしたり、ローカル変更がメンテナンスリリースの上で引き続き適用できるかを再確認したりするのとは、作業の性質が大きく異なる

組み込みイメージの構成方法

  • Debianベースの組み込みイメージは、SoC上でUSBフラッシュドライブから起動してDebianインストーラーを実行する方式ではない
  • ビルドホストでフラッシュ可能なイメージを生成し、それをデバイスへ書き込む方式である
  • 必要な構成要素は次の通り
    • 通常はSoC固有のブートローダー 例: u-boot
    • 通常はSoC固有のLinuxカーネル
    • Debianからそのまま取得したLinuxユーザー空間ベースのルートファイルシステム
    • 3要素をフラッシュ可能イメージへ結合するイメージ組み立てツール
  • イメージ組み立てツールとして一般的なのはmkosi、ELBE、debosである
  • 3つのツールはいずれも自由ソフトウェアであり、ハードウェアへ書き込める決定的なイメージを生成する
  • 保守作業は大幅に減り、アップデートの大半はレシピを書き直すことではなく、イメージ内パッケージをapt方式で更新することになる

debosベースのDebianビルド例

  • debosはYAML レシピを読む
  • レシピは、コマンド実行、ルートファイルシステム作成、設定済みソースからのDebianパッケージインストールといったアクションの一覧で構成される
  • 基本的な流れは次の通り
    • aptlyで、必要なすべてのDebianパッケージのコピーを保持するローカルDebianミラーを運用する
    • Linuxカーネルと、必要ならブートローダーをDebianパッケージとしてビルドし、ミラーに追加する
    • ミラーのスナップショットを作成してタグを付ける
    • そのタグがリリースになる
    • debosがそのミラーを使うよう設定し、対象イメージを作るレシピアクションを書く
    • 必要に応じて、DebianソースパッケージとイメージのSBOM(Software Bill of Materials)をイメージと一緒に保管する
  • ソースパッケージとSBOMの保管は、GPLのソース提供義務やCRAの部材表要件を満たすのに役立つ
  • debsbomのようなツールは、Debianシステムから直接SBOMを生成する

Yoctoを選ぶべき場合

  • 強くカスタマイズされたディストリビューションが必要な場合、Yoctoが適している
    • カスタムユーザー空間
    • カスタムコンパイルフラグ
    • 基盤コンポーネントへの深い変更
  • 既製ディストリビューションでは満たせない厳しいサイズまたは起動時間制約がある場合に適している
  • 一般的なライセンス分類を除外しなければならないライセンス制約がある場合に適している
    • 医療機器、自動車、一部の防衛関連作業など、いくつかの業界ではGPLv3コンポーネントを配布しない
    • YoctoのINCOMPATIBLE_LICENSEメカニズムは、イメージ全体から特定のライセンス系列を除外しやすくする
    • 一般的なDebianベースでは、パッケージを自分で監査して削減する必要がある
  • SoCベンダーの公式サポート経路がYoctoで、BSP品質が堅牢な場合に適している

Yoctoを避けるべき場合

  • アプリケーションを載せて実行するためのモダンなLinuxが必要なだけなら、Yoctoは不要かもしれない
  • ストレージとメモリ予算が一般的なDebianベースイメージを受け入れられるなら、Yoctoの利点は小さくなる
    • 目安となる例は、数百MBのフラッシュと256MB以上のRAMである
  • 製品寿命が長く、自前メンテナンスよりDebian Security Teamに依存したほうがよいなら、Yoctoは避けるのが妥当である

Debianを避けるべき場合

  • Debianパッケージを多数修正または再ビルドしなければならないなら、Debianは不利である
    • 数個のパッケージの再ビルドなら管理可能である
    • 再ビルドした各パッケージは、自分で抱える保守作業になる
    • 数十個のupstreamパッケージにパッチを当てると、Debianメンテナーが代わりにやっていた仕事を自分で再現することになる
    • この規模では、Yoctoのレシピモデルのほうがよりきれいに扱える
  • muslやuClibcのような非glibc libcが必要なら、Debianは適していない
    • Debianのメインアーカイブは全体としてglibcを使用している
    • これを置き換えるには、アーカイブの大部分を自分で再ビルドしなければならない
  • Debian stableが提供するよりはるかに新しいソフトウェアが必要なら、Debianは不利である
    • backportsは一部パッケージには役立つ
    • 新しいコンパイラや新しいランタイムが製品に必要なら、Debian stableとは相性が悪い
    • Debian testingは本番向けではない

判断原則と結論

  • Yoctoを使うかどうかは、意識的に、製品初期に決めるべきである
  • この選択は、製品が現場に展開されたあとでは覆しにくい基盤選択である
  • 迷うなら、既存ディストリビューションから始めたほうがよい
  • 実際の理由が生じてから後でYoctoへ移行するコストは、プロジェクト途中で実質的な利益もないまま何年分もの保守作業を抱え込んでいたと気づくより、はるかに低い
  • Yoctoは、必要なLinuxシステムを正確に構築できる優れたエンジニアリング成果だが、まさにその精密な制御が不要なときには問題になる
  • Buildrootのような他のソースベースのビルドツールにも、ほぼ同じ論理がそのまま当てはまる
  • 独自ディストリビューションを組み立てた瞬間、その保守責任も自分で負うことになる
  • 核心的な結論は明確である
    • 「独自ディストリビューション」は実際には自前メンテナンスを意味する
    • CRAや同様の規制は、そのコストを現実の負担にする
    • 大きく改変したYoctoビルドは、upstreamの修正を無料でそのまま継承できない
    • 各メンテナンスリリースは、レビューと再作業の機会になる
    • mkosi、ELBE、debosでイメージ化したDebianのような既存ディストリビューションは、一般的なケースをはるかに少ないプロジェクト固有の労力で処理できる
    • システムを外科的に制御する必要があるときはYoctoが勝る
    • そうでないなら、Yoctoを選ぶことは、存在しない問題を長く高くつく形で解くことになりうる

関連記事

1件のコメント

 
GN⁺ 21 시간 전
Lobste.rsの反応

  • SoCベンダーの公式サポート経路が Yocto なら、BSPが盤石でなくても、たいていは品質の低いUbuntu移植版よりましだと思う
    Ubuntu移植版はRAUC統合やルートファイルシステムの不変化のような作業を面倒にする。Yoctoとその派生したbash/python方言は本当に嫌いだが、結局そこに縛られている

  • Yoctoコンサルティングを多くしているが、記事で嘆かれている問題にはほとんど遭遇したことがない。普通は逆で、Yoctoが最善な状況でも顧客がどうしても避けようとするので、経営陣を説得しなければならない場合が多い
    ただ Yoctoが嫌われるのは理解できる。難しく、分かりにくく、遅く、ツールももっと良くなれる。それでも実用的な代替があるのかは分からないし、BSD側にも似たようなものがあるのか気になる

    • Yoctoにどれほど近いかは分からないが、FreeBSDで組み込みシステムのイメージを作る一般的な方法は NanoBSD だ
      https://docs.freebsd.org/en/articles/nanobsd/
    • 実運用で深く使ったことはなく、Yoctoより完成度が低いかもしれないが、buildroot にはかなり良いものが入っている
      主に Nerves の文脈で使ったが、Nervesは基本的にbuildroot + fwup + Erlang VMとサポートソフトウェアの組み合わせだ。組み込みLinuxシステムを開発し、パッケージ化・配布するのにかなり快適だった
    • 組み込みLinux/BSDシステムを直接扱ってはいないが、NetBSDを使った立場からすると、ビルドシステムの build.sh だけでも十分に思える
      カーネルとユーザー空間を簡単にクロスコンパイルできる。最後にpkgsrcアプリケーションを追加したり、生成イメージにu-bootのようなブートローダーを入れたりするなら、少しスクリプトが必要かもしれない。アプリケーション向けにそのままカスタマイズできる完成済みの流れではないかもしれないが、土台としては悪くない
    • NetBSD は制約のある環境を対象にクロスコンパイルしやすいように作られており、慣れてしまえばかなり快適だ

  • 組み込み界隈のひどさを少し経験した程度の限られた体験では、こういう用途には NixOS がかなり合っていて、ビルドツールもYoctoよりずっと良かった

    • ARMデバイスでもそうなのか気になる。NixOSエコシステム はそういう機器にはまだ少し早いと思っていた

  • ちょうど会社でRockchipベースのデバイス向け カスタムLinuxカーネルとディストリビューション を企画して作り始めたところなので、タイムリーな記事だ
    BSPはかなり保守するものが多そうで、Debianを「そのまま使う」ほうが、自分がめちゃくちゃに書いたbitbakeジョブよりずっと管理しやすそうに見える。それでもYoctoエコシステム自体はかなり良く、立ち上がりを楽にしてくれる kas や isar のようなツールがある

    • isarのREADMEを見ると、Yoctoではなく Debianベース に見える。両者を混ぜて使うのは一般的なのだろうか
      記事ではYoctoかDebianかのように語られていて、両方を組み合わせるやり方ではなさそうだ