カスタムの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"
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
クラスを継承します。これが私の質問のいくつかです:
kernel-dev
は、kernel
クラスを継承するレシピの一部であるべきではありませんか? ( このセクション 変数用語集の)virtual/kernel
をDEPENDS
変数に追加した場合、それはkernel-dev
が取り込まれることを意味しませんか?kernel-dev
がレシピの依存関係の一部である場合、レシピから/usr/src/kernel
ディレクトリを指すことができませんか? Yoctoメーリングリストのこの返信 によると、私はそうすべきだと思います。ビルド時環境には、次のようなさまざまな環境があることに注意してください。
kernel-dev
はターゲットパッケージであり、perf/oprofileなどのプロファイリングツールで必要となるカーネルシンボルマップなどの特定のもののために、ターゲットシステムのrootfsにインストールします。一部のコンテンツはsysrootsまたは共有workdirで使用できますが、ビルド時には存在しません。
do_install
はビルド時に実行されるため、これはビルドシステムのビルドディレクトリ構造内にあり、ターゲットシステム内にはありません。特に、/usr/src/
は正しくありません。ビルドディレクトリ内のパスである必要があります。 virtual/kernel
do_shared_workdir
タスクは${STAGING_DIR_KERNEL}
にデータを入力するため、スクリプトでそのディレクトリに移動する必要があります。
:
do_install[depends] += "virtual/kernel:do_shared_workdir
do_configure
またはdo_compile
の何もそこのデータにアクセスしないと仮定すると、のような依存関係はユースケースに適しているように見えます。
module
BitBakeクラスを再検討してくださいmodule.bbclass
を確認することをお勧めします。これは、一般的なカーネルモジュールを構築する方法を示しているためです。カスタム関数を使用したり、コマンドを作成したりする場合は、これで問題ありません。オーバーライドするだけです。そのクラスを本当に使いたくないのであれば、そこからインスピレーションを得ることをお勧めします。
virtual/kernel
をDEPENDS
に追加すると、virtual/kernel:do_populate_sysroot
はdo_configure
タスクの前に実行する必要があります。ここではdo_shared_workdir
の依存関係が必要なので、virtual/kernel
のDEPENDS
では不十分です。
kernel-dev
パッケージがビルドされますが、ターゲットイメージにインストールし、実行時に実際のターゲットで使用する必要があります。ビルド時にこれが必要になるため、kernel-dev
は適切ではありません。
kernel-devsrc
パッケージではなく、実行している作業にkernel-dev
パッケージが必要になる可能性があります。
ここで最後の質問に正しく答えられる人はいないと思います。非標準のインストール方法を使用しています。操作方法がわかりません...
そうは言っても、meta/classes /module.bbclassが何をするのか見てみましょう。 makeに関連するいくつかの変数を設定します:KERNEL_SRC=${STAGING_KERNEL_DIR}
、KERNEL_PATH=${STAGING_KERNEL_DIR}
、O=${STAGING_KERNEL_BUILDDIR}
。たぶん、インストーラーはこれらの環境変数のいくつかをサポートしていて、レシピでそれらを設定できますか?