如何编写需要内核源头文件的BitBake驱动程序配方? [英] How to write a BitBake driver recipe which requires kernel source header files?
问题描述
我在BitBake配方中有一个do_install
任务,该任务是我为执行自定义install
脚本的驱动程序编写的.该任务失败,因为安装脚本无法在<the image rootfs>/usr/src/kernel
中找到内核源头文件.该脚本可以在生成的OS上正常运行.
I have a do_install
task in a BitBake recipe which I've written for a driver where I execute a custom install
script. The task fails because the installation script cannot find kernel source header files within <the image rootfs>/usr/src/kernel
. This script runs fine on the generated OS.
这是我食谱的相关部分:
Here's the relevant part of my recipe:
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
,以下是我的相关部分:
I checked changing to if [ ! -d "/usr/src/kernel" ]
, which also failed. install
passes different options to install_drv
, which I have a relevant portion of below:
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
${DRV_PATH}/pci
中的make
目标build:
本质上是这样的:
The make
target build:
within ${DRV_PATH}/pci
is essentially this:
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
中正确获取标头,因为我没有使用make.
I'm a bit unclear if I can 'get' the headers from the STAGING_KERNEL_DIR
properly since I'm not using make.
在meta/classes
目录中提供的kernel.bbclass
中,有以下变量分配:
Within kernel.bbclass
provided in the meta/classes
directory, there is this variable assigment:
# Define where the kernel headers are installed on the target as well as where
# they are staged.
KERNEL_SRC_PATH = "/usr/src/kernel"
此路径随后被打包在此.bbclass
文件中:
This path is then packaged later within that .bbclass
file here:
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频道的建议是使用以下行:
Update (1/21):
A suggestion on the yocto IRC channel was to use the following line:
do_configure[depends] += "virtual/kernel:do_shared_workdir"
,已得到 Yocto项目参考手册,其中指出在1.8版中进行了以下更改:
which is corroborated by the Yocto Project Reference Manual, which states that in version 1.8, there was the following change:
更改了内核构建过程,以将源代码放置在公共共享工作区中,并将构建工件分别放置在源代码树中.从理论上讲,已为内核配方中的大多数常用用法提供了迁移路径,但这可能并非在所有情况下都有效.特别是,用户需要确保在
do_configure
和do_install
之类的功能中正确使用${S}
(源文件)和${B}
(构建工件).对于不继承自kernel-yocto
或不包含linux-yocto.inc
的内核配方,您可能希望参考meta-oe
层中的linux.inc
文件以了解需要进行的更改.作为参考,这是在meta-oe
中的linux.inc
文件被更新的提交.
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 asdo_configure
anddo_install
. For kernel recipes that do not inherit fromkernel-yocto
or includelinux-yocto.inc
, you might wish to refer to thelinux.inc
file in themeta-oe
layer for the kinds of changes you need to make. For reference, here is the commit where thelinux.inc
file inmeta-oe
was updated.
依赖内核源代码并且不继承模块类的食谱可能需要添加对do_shared_workdir
内核任务的显式依赖关系,例如:
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"
但是我在将其应用于我的食谱时遇到了困难.据我了解,我应该可以将上面的行更改为:
But I'm having difficulties applying this to my recipe. From what I understand, I should be able to change the above line to:
do_install[depends] += "virtual/kernel:do_shared_workdir"
这意味着do_install
任务现在必须在virtual/kernel
配方的do_shared_workdir
任务之后运行,这意味着我应该能够使用共享的工作目录(请参阅下面的问题3),但是我仍然有相同的缺少内核头文件的问题.
Which would mean that the do_install
task now must be run after do_shared_workdir
task of the virtual/kernel
recipe, which means that I should be able to work with the shared workdir (see Question 3 below), but I still have the same missing kernel header issue.
I'm using a custom linux kernel (v3.14) from git.kernel.org. which inherits the kernel
class. Here are some of my questions:
- 软件包
kernel-dev
不应成为继承kernel
类的任何配方的一部分吗? (变量词汇表的本节 ) - 如果将
virtual/kernel
添加到DEPENDS
变量中,这是否意味着会引入kernel-dev
? - 如果
kernel-dev
是我的食谱依赖项的一部分,我是否无法从我的食谱中指向/usr/src/kernel
目录?根据在Yocto邮件列表上的回复,我认为我应该. -
如何正确引用内核源头文件,最好不更改安装脚本?
- Shouldn't the package
kernel-dev
be a part of any recipe which inherits thekernel
class? (this section of the variables glossary) - If I add the
virtual/kernel
to theDEPENDS
variable, wouldn't that mean that thekernel-dev
would be brought in? - If
kernel-dev
is part of the dependencies of my recipe, wouldn't I be able to point to the/usr/src/kernel
directory from my recipe? According to this reply on the Yocto mailing list, I think I should. How can I properly reference the kernel source header files, preferably without changing the installation script?
推荐答案
考虑您的环境
请记住,构建时环境中存在不同的环境,包括:
Consider your Environment
Remember that there are different environments within the the build time environment, consisting of:
- sysroots
- 对于内核,为共享工作目录
- 目标软件包
kernel-dev
是目标软件包,您可以将其安装到目标系统的rootfs中,以用于某些特性,例如性能分析工具(如perf/oprofile)所需的内核符号映射.尽管它的某些内容在sysroots或共享的工作目录中可用,但它在构建时不存在.
kernel-dev
is a target package, which you'd install into the rootfs of the target system for certain things like kernel symbol maps which are needed by profiling tools like perf/oprofile. It is not present at build time although some of its contents are available in the sysroots or shared workdir.
您的do_install
在构建时运行,因此它在构建系统的构建目录结构中,而不是在目标系统中.特别是/usr/src/
不会正确,它需要是您的构建目录中的某些路径. virtual/kernel
do_shared_workdir
任务将填充${STAGING_DIR_KERNEL}
,因此您需要在脚本中更改为该目录.
Your do_install
runs at build time so this is within the build directory structures of the build system, not the target one. In particular, /usr/src/
won't be correct, it would need to be some path within your build directory. The virtual/kernel
do_shared_workdir
task populates ${STAGING_DIR_KERNEL}
so you would want to change to that directory in your script.
该:
do_install[depends] += "virtual/kernel:do_shared_workdir
假设do_configure
或do_compile
中没有任何内容访问那里的数据,那么
依赖性看起来很适合您的用例.
dependency like looks correct for your use case, assuming nothing in do_configure
or do_compile
accesses the data there.
在建议阅读module.bbclass
时,其他答案是正确的,因为这说明了如何构建通用内核模块.如果您想使用自定义函数或make命令,这很好,您可以覆盖它们.如果您真的不想使用该类,我建议您从中汲取灵感.
The other answers are correct in the recommendation to look at module.bbclass
, since this illustrates how common kernel modules can be built. If you want to use custom functions or make commands, this is fine, you can just override them. If you really don't want to use that class, I would suggest taking inspiration from it though.
在DEPENDS
中添加virtual/kernel
意味着virtual/kernel:do_populate_sysroot
必须在我们的do_configure
任务之前运行.由于此处需要do_shared_workdir
的依赖项,因此virtual/kernel
上的DEPENDS
是不够的.
Adding virtual/kernel
to DEPENDS
means virtual/kernel:do_populate_sysroot
must run before our do_configure
task. Since you need a dependency for do_shared_workdir
here, a DEPENDS
on virtual/kernel
is not enough.
将构建kernel-dev
软件包,但是随后需要将其安装到目标映像中,并在运行时在实际目标上使用.您需要在构建时使用它,因此kernel-dev
不适合.
The kernel-dev
package would be built, however it would then need to be installed into your target image and used at runtime on a real target. You need this at build time so kernel-dev
is not appropriate.
您可能希望使用kernel-devsrc
软件包而不是kernel-dev
软件包.
You'd likely want the kernel-devsrc
package for what you're doing, not the kernel-dev
package.
这篇关于如何编写需要内核源头文件的BitBake驱动程序配方?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!