How to write a BitBake driver recipe which requires kernel source header files?

Question

Introduction

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

Answer 1

I don't think anyone can properly answer that last question here. You are using a non-standard install method: we can't know how to interact with it...

That said, take a look at what meta/classes/module.bbclass does. It sets several related variables for make: KERNEL_SRC=${STAGING_KERNEL_DIR}, KERNEL_PATH=${STAGING_KERNEL_DIR}, O=${STAGING_KERNEL_BUILDDIR}. Maybe your installer supports some of these environment variables and you could set them in your recipe?

Answer 2

Consider your Environment

Remember that there are different environments within the the build time environment, consisting of:

• sysroots
• in the case of kernels, a shared work directory
• target packages

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.

Point to the Correct Directories

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.

Adding a Task Dependency

The:

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

dependency like looks correct for your use case, assuming nothing in do_configure or do_compile accesses the data there.

Reconsider the module BitBake class

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.

Task Dependencies

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.

Answer to Question 3

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.

Other Suggestions

You'd likely want the kernel-devsrc package for what you're doing, not the kernel-dev package.