Sanitized kernel headers

Sanitized kernel headers

[Peter Kjellerstedt]

In a recent commit 
(http://cgit.openembedded.org/openembedded-core/commit/?id=c27ac156bcaf3193d52f456480947b0cfaef3c72), 
Richard added a big warning about not forking the 
linux-libc-headers recipe to get at specific kernel 
headers for user space. As a consequence I thought I 
should remove our fork of linux-libc-headers and instead 
use the suggested method of including the needed files 
from ${STAGING_KERNEL_DIR} in the recipes that need them.

However, I soon realized that what I need are the sanitized 
headers that are generated by running "make headers_install" 
in the kernel sources. So what I then did was to create a 
simple bbclass that generates them for me and makes them 
available for my recipe:

---- %< ------------- kernel-headers.bbclass --------------
DEPENDS += "virtual/kernel"

PACKAGE_ARCH = "${MACHINE_ARCH}"

inherit kernel-arch

KINCLUDES ?= "${WORKDIR}/kernel-includes"

do_compile_prepend() {
	mkdir -p ${KINCLUDES}
	oe_runmake -C ${STAGING_KERNEL_DIR} headers_install INSTALL_HDR_PATH=${KINCLUDES}
}
--------------------------------------------------- >% ----

After that I could simply do 'inherit kernel-headers' and 
'CFLAGS += "-I${KINCLUDES}/includes"' in my recipe to get 
at the sanitized kernel headers.

But, it seems somewhat wasteful for each recipe that need 
those headers to do that. Wouldn't it be an idea to provide 
the sanitized headers in ${STAGING_KERNEL_DIR}/usr/include 
(which would be the default path for make headers_install) 
by default?

//Peter

Re: Sanitized kernel headers

[Bruce Ashfield]

On 13-10-02 09:45 AM, Peter Kjellerstedt wrote:
> In a recent commit
> (http://cgit.openembedded.org/openembedded-core/commit/?id=c27ac156bcaf3193d52f456480947b0cfaef3c72),
> Richard added a big warning about not forking the
> linux-libc-headers recipe to get at specific kernel
> headers for user space. As a consequence I thought I
> should remove our fork of linux-libc-headers and instead
> use the suggested method of including the needed files
> from ${STAGING_KERNEL_DIR} in the recipes that need them.
>
> However, I soon realized that what I need are the sanitized
> headers that are generated by running "make headers_install"
> in the kernel sources. So what I then did was to create a
> simple bbclass that generates them for me and makes them
> available for my recipe:
>
> ---- %< ------------- kernel-headers.bbclass --------------
> DEPENDS += "virtual/kernel"
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> inherit kernel-arch
>
> KINCLUDES ?= "${WORKDIR}/kernel-includes"
>
> do_compile_prepend() {
> 	mkdir -p ${KINCLUDES}
> 	oe_runmake -C ${STAGING_KERNEL_DIR} headers_install INSTALL_HDR_PATH=${KINCLUDES}
> }
> --------------------------------------------------- >% ----
>
> After that I could simply do 'inherit kernel-headers' and
> 'CFLAGS += "-I${KINCLUDES}/includes"' in my recipe to get
> at the sanitized kernel headers.
>
> But, it seems somewhat wasteful for each recipe that need
> those headers to do that. Wouldn't it be an idea to provide
> the sanitized headers in ${STAGING_KERNEL_DIR}/usr/include
> (which would be the default path for make headers_install)
> by default?

For developers already comfortable with using a previously forked
libc-headers, I don't see much of a problem. There of course is still
a potential issue if these parallel, machine specific headers are
generated from a kernel tree that modifies files which are already
exported and made available via the libc-headers package.

That being said, the risk is actually less in this situation, since
a different include path is required, hence an explicit acknowledgment
that something not quite standard is happening.

I've proposed similar solutions in the past, including installing
the headers into the sysroot along side of the libc-headers in
"usr-alt/", or "kernel-headers/", rather than within the kernel
staging dir, since the staging dir is often tar'd up and added to
things like the kernel-dev package or SDKs .. and if not properly
installed, you can clash with the libc usr/include/linux headers.

But yes, either way, I'm all for doing this once, making them
available in a oe-core "standard" location, as long as it isn't
picked up by default include paths.

If you want to open up something in the bugzilla, we can take care
of this early in the yocto 1.6 cycle, since at this point in 1.5,
we don't want to jiggle much of anything :)

Cheers,

Bruce

>
> //Peter
>