linux-kernel - 如何编写需要内核源头文件的 BitBake 驱动程序配方？

Question

简介

我有一个do_install我为驱动程序编写的 BitBake 配方中的任务，我在其中执行自定义 install脚本。任务失败，因为安装脚本在 <the image rootfs>/usr/src/kernel 内找不到内核源头文件。该脚本在生成的操作系统上运行良好。

发生了什么

这是我的食谱的相关部分:

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

make目标build: ${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.

我有点不清楚是否可以从 STAGING_KERNEL_DIR 中“获取” header 正确，因为我没有使用 make。

在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 channel 的建议是使用以下行:

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

这得到了 Yocto Project Reference Manual 的证实，其中指出在 1.8 版本中，有以下更改:

The kernel build process was changed to place the source in a common shared work area and to place build artifacts separately in the source code tree. In theory, migration paths have been provided for most common usages in kernel recipes but this might not work in all cases. In particular, users need to ensure that ${S} (source files) and ${B} (build artifacts) are used correctly in functions such as do_configure and do_install. For kernel recipes that do not inherit from kernel-yocto or include linux-yocto.inc, you might wish to refer to the linux.inc file in the meta-oe layer for the kinds of changes you need to make. For reference, here is the commit where the linux.inc file in meta-oewas updated.

Recipes that rely on the kernel source code and do not inherit the module classes might need to add explicit dependencies on the do_shared_workdir kernel task, for example:

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

但是我很难将其应用到我的食谱中。据我了解，我应该能够将上面的行更改为:

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

这意味着 do_install现在任务必须在 do_shared_workdir 之后运行virtual/kernel的任务配方，这意味着我应该能够使用共享工作目录(请参见下面的问题 3)，但我仍然遇到相同的丢失内核头问题。

我的问题

我正在使用 git.kernel.org 中的自定义 Linux 内核 (v3.14) 。它继承了 kernel类(class)。以下是我的一些问题:

1. 包裹不应该kernel-dev成为继承 kernel 的任何食谱的一部分类(class)？ (变量术语表的this section)
2. 如果我添加virtual/kernel到DEPENDS变量，这不是意味着 kernel-dev会被引进吗？
3. 如果kernel-dev是我的食谱依赖项的一部分，我是否能够指向 /usr/src/kernel我的食谱目录？根据this reply on the Yocto mailing list ，我想我应该。
4. 如何正确引用内核源头文件，最好不更改安装脚本？

Answer 1

考虑您的环境

请记住，构建时环境中有不同的环境，包括:

• 系统根目录
• 对于内核来说，是一个共享工作目录
• 目标包

kernel-dev 是一个目标包，您可以将其安装到目标系统的 rootfs 中，以用于某些功能，例如 perf/oprofile 等分析工具所需的内核符号映射。尽管它的一些内容在 sysroots 或共享工作目录中可用，但它在构建时不存在。

指向正确的目录

您的 do_install 在构建时运行，因此它位于构建系统的构建目录结构中，而不是目标目录结构中。特别是， /usr/src/ 将不正确，它需要是构建目录中的某个路径。 virtual/kernel do_shared_workdir 任务会填充 ${STAGING_DIR_KERNEL}，因此您需要在脚本中更改到该目录。

添加任务依赖项

:

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

假设 do_configure 或 do_compile 中没有任何内容访问那里的数据，类似的依赖关系看起来适合您的用例。

重新考虑模块 BitBake 类

建议查看 module.bbclass 的其他答案是正确的，因为这说明了如何构建通用内核模块。如果您想使用自定义函数或 make 命令，这很好，您只需覆盖它们即可。如果您确实不想使用该类，我建议您从中获取灵感。

任务依赖关系

将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 包。