web-dev-qa-db-ja.com

カーネルソースヘッダーファイルを必要とするBitBakeドライバーレシピを作成するにはどうすればよいですか？

前書き

カスタムのinstallスクリプトを実行するドライバー用に作成したBitBakeレシピにdo_installタスクがあります。インストールスクリプトが<the image rootfs>/usr/src/kernel内のカーネルソースヘッダーファイルを見つけることができないため、タスクは失敗します。このスクリプトは、生成されたOSで正常に実行されます。

何が起こっていますか

これが私のレシピの関連部分です：

SRC_URI += "file://${TOPDIR}/example"
DEPENDS += " virtual/kernel linux-libc-headers "
do_install () {  
   ( cd ${TOPDIR}/example/Install ; ./install )
}

installスクリプトの関連部分は次のとおりです。

if [ ! -d "/usr/src/kernel/include"  ]; then
  echo ERROR: Linux kernel source include directory not found.  
  exit 1
fi
cd /usr/src/kernel
make scripts
...
./install_drv pci ${DRV_ARGS}

if [ ! -d "/usr/src/kernel" ]への変更を確認しましたが、これも失敗しました。 installはさまざまなオプションをinstall_drvに渡します。これには、以下の関連部分があります。

cd ${DRV_PATH}/pci
make NO_SYSFS=${ARG_NO_SYSFS} NO_INSTALL=${ARG_NO_INSTALL} ${ARGS_HWINT}
if [ ${ARG_NO_INSTALL} == 0 ]; then
  if [ `/sbin/lsmod | grep -ci "uceipci"` -eq 1 ]; then
    ./unload_pci
  fi
  ./load_pci DEBUG=${ARG_DEBUG}
fi

build:内のmakeターゲット${DRV_PATH}/pciは基本的に次のとおりです。

make -C /usr/src/kernel SUBDIRS=${PWD} modules

私の研究

linux-libc-headers.inc内でこれらのコメントが関連していることがわかりました：

# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put 
# this simply, you DO NOT.
#
# Why? These headers are used to build the libc. If you customise the 
# headers you are customising the libc and the libc becomes machine
# specific. Most people do not add custom libc extensions to the kernel
# and have a machine specific libc.
#
# But you have some kernel headers you need for some driver? That is fine
# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
# This will make the package using them machine specific but this is much
# better than having a machine specific C library. This does mean your 
# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
# makes total sense.
#
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom 
# one.

Makeを使用していないため、STAGING_KERNEL_DIRからヘッダーを適切に「取得」できるかどうかは少しわかりません。

kernel.bbclassディレクトリで提供されるmeta/classes内には、次の変数割り当てがあります。

# Define where the kernel headers are installed on the target as well as where
# they are staged.
KERNEL_SRC_PATH = "/usr/src/kernel"

このパスは、後でその.bbclassファイル内にパッケージ化されます。

PACKAGES = "kernel kernel-base kernel-vmlinux kernel-image kernel-dev kernel-modules"
...
FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH} /lib/modules/${KERNEL_VERSION}/build"

更新（1/21）：

Yocto IRCチャネルに関する提案は、次の行を使用することでした。

do_configure[depends] += "virtual/kernel:do_shared_workdir"

これは Yocto Project Reference Manual によって裏付けられており、バージョン1.8では次の変更があったと述べています。

カーネルビルドプロセスが変更され、ソースが共通の共有作業領域に配置され、ビルドアーティファクトがソースコードツリーに個別に配置されるようになりました。理論的には、移行パスはカーネルレシピの最も一般的な使用法に提供されていますが、これはすべての場合に機能するとは限りません。特に、ユーザーは、${S}（ソースファイル）と${B}（ビルドアーティファクト）がdo_configureやdo_installなどの関数で正しく使用されていることを確認する必要があります。 kernel-yoctoを継承しない、またはlinux-yocto.incを含むカーネルレシピの場合、必要な変更の種類については、linux.incレイヤーのmeta-oeファイルを参照することをお勧めします。作る。参考までに、linux.incのmeta-oeファイルが更新されたコミットを次に示します。

カーネルソースコードに依存し、モジュールクラスを継承しないレシピでは、次のようにdo_shared_workdirカーネルタスクに明示的な依存関係を追加する必要がある場合があります。

do_configure[depends] += "virtual/kernel:do_shared_workdir"

しかし、これをレシピに適用するのに苦労しています。私が理解していることから、上記の行を次のように変更できるはずです。

do_install[depends] += "virtual/kernel:do_shared_workdir"

つまり、do_installタスクはdo_shared_workdirレシピのvirtual/kernelタスクの後に実行する必要があります。つまり、共有workdirで作業できるはずです（以下の質問3を参照）。 、しかし、私はまだ同じカーネルヘッダーの欠落の問題を抱えています。

私の質問

git.kernel.org のカスタムLinuxカーネル（v3.14）を使用しています。これはkernelクラスを継承します。これが私の質問のいくつかです：

  1. パッケージkernel-devは、kernelクラスを継承するレシピの一部であるべきではありませんか？ （ このセクション 変数用語集の）
  2. virtual/kernelをDEPENDS変数に追加した場合、それはkernel-devが取り込まれることを意味しませんか？
  3. kernel-devがレシピの依存関係の一部である場合、レシピから/usr/src/kernelディレクトリを指すことができませんか？ Yoctoメーリングリストのこの返信 によると、私はそうすべきだと思います。
  4. できればインストールスクリプトを変更せずに、カーネルソースヘッダーファイルを適切に参照するにはどうすればよいですか？
linux-kernelheader-filesyoctobitbakeopenembedded
13
karobar

あなたの環境を考慮してください

ビルド時環境には、次のようなさまざまな環境があることに注意してください。

  • sysroots
  • カーネルの場合、共有作業ディレクトリ
  • ターゲットパッケージ

kernel-devはターゲットパッケージであり、perf/oprofileなどのプロファイリングツールで必要となるカーネルシンボルマップなどの特定のもののために、ターゲットシステムのrootfsにインストールします。一部のコンテンツはsysrootsまたは共有workdirで使用できますが、ビルド時には存在しません。

正しいディレクトリをポイントする

do_installはビルド時に実行されるため、これはビルドシステムのビルドディレクトリ構造内にあり、ターゲットシステム内にはありません。特に、/usr/src/は正しくありません。ビルドディレクトリ内のパスである必要があります。 virtual/kerneldo_shared_workdirタスクは${STAGING_DIR_KERNEL}にデータを入力するため、スクリプトでそのディレクトリに移動する必要があります。

タスクの依存関係の追加

：

do_install[depends] += "virtual/kernel:do_shared_workdir

do_configureまたはdo_compileの何もそこのデータにアクセスしないと仮定すると、のような依存関係はユースケースに適しているように見えます。

moduleBitBakeクラスを再検討してください

module.bbclassを確認することをお勧めします。これは、一般的なカーネルモジュールを構築する方法を示しているためです。カスタム関数を使用したり、コマンドを作成したりする場合は、これで問題ありません。オーバーライドするだけです。そのクラスを本当に使いたくないのであれば、そこからインスピレーションを得ることをお勧めします。

タスクの依存関係

virtual/kernelをDEPENDSに追加すると、virtual/kernel:do_populate_sysrootはdo_configureタスクの前に実行する必要があります。ここではdo_shared_workdirの依存関係が必要なので、virtual/kernelのDEPENDSでは不十分です。

質問3への回答

kernel-devパッケージがビルドされますが、ターゲットイメージにインストールし、実行時に実際のターゲットで使用する必要があります。ビルド時にこれが必要になるため、kernel-devは適切ではありません。

その他の提案

kernel-devsrcパッケージではなく、実行している作業にkernel-devパッケージが必要になる可能性があります。

13
Richard Purdie

ここで最後の質問に正しく答えられる人はいないと思います。非標準のインストール方法を使用しています。操作方法がわかりません...

そうは言っても、meta/classes /module.bbclassが何をするのか見てみましょう。 makeに関連するいくつかの変数を設定します：KERNEL_SRC=${STAGING_KERNEL_DIR}、KERNEL_PATH=${STAGING_KERNEL_DIR}、O=${STAGING_KERNEL_BUILDDIR}。たぶん、インストーラーはこれらの環境変数のいくつかをサポートしていて、レシピでそれらを設定できますか？

1
Jussi Kukkonen