yocto

Yocto 入門

標準的な Yocto の知識についてまとめる。Yocto 開発環境の構築には、git clone を使う。(pyro で 200MB)

git clone git://git.yoctoproject.org/poky

以下の項目が含まれる

  • oe-init-build-env: 環境設定スクリプト
  • bitbake, bitbake-layers, oe-pkgdata-util: 各種コマンド

用語

  • layer: conf/layer.conf の置いてあるディレクトリの事
  • recipe: ソフトウェアの単位 .bb ファイルの事
  • package: 生成物インストールの単位 dev doc 等に分割出来る。

Bitbake の動作

bitbake recipe で何が起こるか?

  • Bitbake は conf/bblayers.conf を読む
  • Bitbake は BBLAYERS を読む
    • BBLAYER には空白区切りでディレクトリが書いてある (例: ${METADIR}/poky/meta)
      • METADIR とは poky ディレクトリ
    • Bitbake は BBLAYER それぞれの conf/layer.conf を読む
  • Bitbake は BBPATH を読む (例: BBPATH = "${TOPDIR}")
    • TOPDIR は build ディレクトリを指す
    • Bitbake は BBPATH の conf/bitbake.conf を読む
      • 謎: 実際には conf.bitbake は build では無く、poky/meta/ にある。
      • include によって local.conf が読まれる。
  • Bitbake は BBFILES に空白区切りで指定された .bb ファイルを読む
  • 指定した recipe を実行

layer が有効になるまで

  • build/conf/layer.conf が生成される
    • todo: どうやって?
  • build/conf/layer.conf で BBLAYERS に追加される。

ファイルの種類

  • recipe (bb)
    • ファイル名形式: ${PN}_${PV}.bb
      • busybox_1.22.1.bb: 1.22 を明示的に指定
      • busybox_git.bb: 最新バージョンを指定
    • ビルド手順を示す。PROVIDES を定義する。
  • bbappend
    • ファイル名形式: ${PN}_${PV}.bbappend
    • レイヤ内に記述する。

conf

コマンド

  • bitbake (recipe) でビルド
  • bitbake -e (recipe) 変数の確認
  • bitbake-layers show-layers 読み込むレイヤの表示
  • bitbake-layers show-recipes 読み込むレシピの表示
  • oe-pkgdata-util list-pkgs パッケージリストを表示
  • oe-pkgdata-util list-pkg-files (package) パッケージに含まれるファイル

生成物のディレクトリ構成

  • tmp/deploy/
    • ビルド結果。
  • tmp/sysroots/(machine)/
    • 互換性のためにある。マシンごとに必要なファイルが置いてあった。
  • TMPDIR
    • ${TOPDIR}/tmp
  • WORKDIR
    • ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} ... build/tmp/work/機種/レシピ/バージョン/
  • build/tmp/work/tunearch/recipename/version/
  • build/tmp/work/tunearch/recipename/version/image
    • do_install の結果 ${D} 変数の結果
  • build/tmp/work/tunearch/recipename/version/sysroot-destdir/
    • do_populate_sysroot の結果
  • build/tmp/work/tunearch/recipename/version/package/
    • do_package の結果 (パッケージ分割前)
  • build/tmp/work/tunearch/recipename/version/package-split/
    • do_package の結果 (パッケージ分割後)
  • build/tmp/work/tunearch/recipename/version/pkgdata/
    • 依存情報を持つ。PKGDATA_DIR で参照。

変数

変数のスコープは Variable Context 記述されている。

デフォルト値が local.conf, bblayers.conf, poky/meta/conf/bitbake.conf 等で定義されているので bitbake -e (recipe) で確認する。

あるレシピで定義した変数を、他のレシピから参照する事は出来ない。グローバル変数をレシピで再定義しても他のレシピからは見えない。

  • bblayers.conf のスコープ
    • BBLAYER
      • 追加するレイヤのリスト
      • レイヤとは conf/layer.conf が存在するディレクトリ。layer.conf 内でレシピ等を指定する。
  • local.conf のスコープ
    • BBFILES
      • レシピ (bb と bbappend) のリスト
    • BBMASK
      • あるレシピ (bb と bbappend) を取り除く。正規表現パターンを記述。
  • layer.conf のスコープ
  • recipe のスコープ
    • PN
      • recipe_0.1.bb の場合 recipe となる。
    • B
      • ビルド結果を置く。S と同じでも良い。
    • D
      • ${WORKDIR}/image do_install でここに書き込む
    • DEPENDS
      • ビルド時の依存リスト。大体レシピ名 (PN) や PROVIDES に指定された値を書く。package name ではない。
    • WORKDIR
      • レシピごとの作業ディレクトリ
    • S
      • ソースコードの場所。git の場合自分で設定する必要がある。
    • FILES
      • package に含むファイルやディレクトリ。${D} 内のディレクトリに応じて予めどこがどのパッケージになるか大体 poky/meta/conf/bitbake.conf で決まっている
        • FILES_${PN} のように指定すると default pacakge
        • FILES_${PN}-dev のように指定すると {PN}-dev pacakge
    • SRCREV
      • git 等の revision
    • AUTOREV

Fakeroot

do_install では、生成物を ${D} にコピーするが、その際にユーザ権限の設定等をしたい。本来なら root じゃないとそういう操作は出来ないはずだが、bitbake では通常ユーザでもユーザ権限の操作が出来るように Fakeroot という仕組みでなんちゃって Root 権限を実現している。

Fakeroot 環境では LD_PRELOAD でシステムコールを横取りし環境下のプログラムに root 権限があるかのように思わせるが、実際には ${WORKDIR}/pseudo/files.db にある sqlite3 ファイルで権限を管理している。試しにテーブルを見てみると、何やらそれっぽいデータが出て来る。

$ ./tmp/sysroots/x86_64-linux/usr/bin/sqlite3 ./tmp/work/armv7vehf-neon-vfpv4-agl-linux-gnueabi/weston/1.11.0-r0/pseudo/files.db "select * from files;" | head
2|/work/build/tmp/work/armv7vehf-neon-vfpv4-agl-linux-gnueabi/weston/1.11.0-r0/temp/log.do_install.6002|64770|23156|0|0|33188|0|0
3|/work/build/tmp/buildstats/20170913141538/weston-1.11.0-r0/do_install|64770|23157|0|0|33188|0|0
4|/work/build/tmp/work/armv7vehf-neon-vfpv4-agl-linux-gnueabi/weston/1.11.0-r0/temp/run.useradd_sysroot.6002|64770|23158|0|0|33277|0|0
5|/work/build/tmp/work/armv7vehf-neon-vfpv4-agl-linux-gnueabi/weston/1.11.0-r0/image|64770|22169642|0|0|16877|0|0
6|/work/build/tmp/work/armv7vehf-neon-vfpv4-agl-linux-gnueabi/weston/1.11.0-r0/temp/run.do_install|64770|23159|0|0|41471|0|0
7|/work/build/tmp/work/armv7vehf-neon-vfpv4-agl-linux-gnueabi/weston/1.11.0-r0/temp/run.do_install.6002|64770|23160|0|0|33277|0

イメージ作成の時に ${WORKDIR}/pseudo/files.db に基づいて権限を設定してやれば一般ユーザで作業しても root で作ったかのようにちゃんと権限のついたイメージが出来るという仕組みらしい。