staging & using kernel headers

Hello Koen & co.,

I recently bumped into a problem with recipes ti-dmai and gstreamer-ti when they included the kernel headers. These headers were staged by kernel.bbclass sysroot_stage_all_append() with a lot of manual copying and manipulating links and such, rather than using 'oe_runmake headers_install'. Back in October Koen explained this
(http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is because some recipes use private kernel API. The result of this with my 2.6.38 kernel

is that I get a warning-turned-error from linux/types.h that "Attempt to use kernel headers from user space".

ti-dmai_svn.bb hacks this (self-admittedly) by defining _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to modify the recipe to enable the define to actually get passed as a compile option. For gstreamer-ti, there was no such hack in place, but it was needed for the same reason.

I would think it is a common requirement for recipes to include kernel headers, and this warning has been around since 2.6.32. I got around it with gstreamer-ti by installing the headers with headers_install into a subdir of the headers directory set up currently by kernel.bbclass, and pointing the gstreamer-ti recipe at that, but I'm not sure if there's a better way.

If there are some recipes that need internal kernel sources staged for them, then it seems to me that we need both sets of kernel headers: one exported to userspace (with headers_install) and one that is not. Right? Can we agree on a standard place/manner for this?

Below is my patch to get gstreamer-ti working, for illustration.

-Michael

From 71b3762ad5f6e7a8553a6b780296f7e994513f0b Mon Sep 17 00:00:00 2001
From: Michael Jones <[email protected]>
Date: Thu, 17 Mar 2011 17:23:53 +0100
Subject: [PATCH] install kernel headers exported for userspace

kernel.bbclass already copies and manipulates kernel headers into sysroot, but it doesn't export them properly using "make headers_install" which leads to a compiler error/warning in linux/types.h:

"Attempt to use kernel headers from user space, see
http://kernelnewbies.org/KernelHeaders"

---

classes/kernel.bbclass      |    5 +++++
recipes/ti/gstreamer-ti.inc |    2 +-
2 files changed, 6 insertions(+), 1 deletions(-)

classes/kernel.bbclass +5 -0

index 422bcd7..6b46d51 100644
@@ -210,6 +210,11 @@ sysroot_stage_all_append() {
 	[ -e Module.symvers ] && install -m 0644 Module.symvers $kerneldir/
 
 	cp -fR scripts $kerneldir/
+
+	# install kernel headers in the proper manner to export them
+	# for userspace programs
+	userspace_hdrs=${kerneldir}/userspace
+	oe_runmake headers_install INSTALL_HDR_PATH=${userspace_hdrs} ARCH=${ARCH}
 }
 
 kernel_do_configure() {

recipes/ti/gstreamer-ti.inc +0 -0

index 905e192..04d990f 100644
@@ -72,7 +72,7 @@ CPPFLAGS_append = " -DPlatform_${PLATFORM}"

export ENCODE_COMBO = "${installdir}/ti-codecs-server/encodeCombo.x64P"
export DECODE_COMBO = "${installdir}/ti-codecs-server/decodeCombo.x64P"
# Makefile also expects to be able to find the kernel headers from the envirionment

recipes/ti/gstreamer-ti.inc +1 -1

-export LINUXKERNEL_INSTALL_DIR = "${STAGING_KERNEL_DIR}"
+export LINUXKERNEL_INSTALL_DIR = "${STAGING_KERNEL_DIR}/userspace"

do_configure_prepend() {
# PSP kernel is based on older DSS. we need to replace linux/omapfb.h with mach/omapfb.h

Signature · 6 lines

1.7.4.1


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

CC ing oe-core since we have kernel.bbclass patches there as well.

Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven:

Quoted 10 lines

Hello Koen & co.,

I recently bumped into a problem with recipes ti-dmai and gstreamer-ti when they included the kernel headers. These headers were staged by kernel.bbclass sysroot_stage_all_append() with a lot of manual copying and manipulating links and such, rather than using 'oe_runmake headers_install'. Back in October Koen explained this
(http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is because some recipes use private kernel API. The result of this with my 2.6.38 kernel

DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're trying to get that addressed internally.

Quoted 21 lines

is that I get a warning-turned-error from linux/types.h that "Attempt to use kernel headers from user space".

ti-dmai_svn.bb hacks this (self-admittedly) by defining _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to modify the recipe to enable the define to actually get passed as a compile option. For gstreamer-ti, there was no such hack in place, but it was needed for the same reason.

I would think it is a common requirement for recipes to include kernel headers, and this warning has been around since 2.6.32. I got around it with gstreamer-ti by installing the headers with headers_install into a subdir of the headers directory set up currently by kernel.bbclass, and pointing the gstreamer-ti recipe at that, but I'm not sure if there's a better way.

If there are some recipes that need internal kernel sources staged for them, then it seems to me that we need both sets of kernel headers: one exported to userspace (with headers_install) and one that is not. Right? Can we agree on a standard place/manner for this?

Quoted 1 line

Below is my patch to get gstreamer-ti working, for illustration.

I don't really have a better suggestion, apart from adding a var in e.g. bitbake.conf to point to the userspace stuff.

We might even do the reverse, stage the full set into $kernel_dir/private and the userspace ones in $kernel_dir, that would make it more clear which recipes need internal API.

Quoted 38 lines · Koen Kooi

CC ing oe-core since we have kernel.bbclass patches there as well.

Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven:

Quoted 10 lines

Hello Koen & co.,

I recently bumped into a problem with recipes ti-dmai and gstreamer-ti when they included the kernel headers. These headers were staged by kernel.bbclass sysroot_stage_all_append() with a lot of manual copying and manipulating links and such, rather than using 'oe_runmake headers_install'. Back in October Koen explained this
(http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is because some recipes use private kernel API. The result of this with my 2.6.38 kernel

DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're trying to get that addressed internally.

Quoted 21 lines

is that I get a warning-turned-error from linux/types.h that "Attempt to use kernel headers from user space".

ti-dmai_svn.bb hacks this (self-admittedly) by defining _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to modify the recipe to enable the define to actually get passed as a compile option. For gstreamer-ti, there was no such hack in place, but it was needed for the same reason.

I would think it is a common requirement for recipes to include kernel headers, and this warning has been around since 2.6.32. I got around it with gstreamer-ti by installing the headers with headers_install into a subdir of the headers directory set up currently by kernel.bbclass, and pointing the gstreamer-ti recipe at that, but I'm not sure if there's a better way.

If there are some recipes that need internal kernel sources staged for them, then it seems to me that we need both sets of kernel headers: one exported to userspace (with headers_install) and one that is not. Right? Can we agree on a standard place/manner for this?

Quoted 7 lines

Quoted 1 line

Below is my patch to get gstreamer-ti working, for illustration.

I don't really have a better suggestion, apart from adding a var in e.g. bitbake.conf to point to the userspace stuff.

We might even do the reverse, stage the full set into $kernel_dir/private and the userspace ones in $kernel_dir, that would make it more clear which recipes need internal API.

Anything using internal kernel headers is effectively kernel module like and should be using STAGING_DIR_KERNEL. There should be a complete set of headers available there, particularly after recent improvements to kernel.bbclass in oecore. Note that using kernel headers like this effectively makes the package machine specific since the kernel is machine specific.

Cheers,

Richard

Quoted 47 lines · Richard Purdie

Quoted 38 lines · Koen Kooi

CC ing oe-core since we have kernel.bbclass patches there as well.

Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven:

Quoted 10 lines

Hello Koen & co.,

I recently bumped into a problem with recipes ti-dmai and gstreamer-ti when they included the kernel headers. These headers were staged by kernel.bbclass sysroot_stage_all_append() with a lot of manual copying and manipulating links and such, rather than using 'oe_runmake headers_install'. Back in October Koen explained this
(http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is because some recipes use private kernel API. The result of this with my 2.6.38 kernel

DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're trying to get that addressed internally.

Quoted 21 lines

is that I get a warning-turned-error from linux/types.h that "Attempt to use kernel headers from user space".

ti-dmai_svn.bb hacks this (self-admittedly) by defining _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to modify the recipe to enable the define to actually get passed as a compile option. For gstreamer-ti, there was no such hack in place, but it was needed for the same reason.

I would think it is a common requirement for recipes to include kernel headers, and this warning has been around since 2.6.32. I got around it with gstreamer-ti by installing the headers with headers_install into a subdir of the headers directory set up currently by kernel.bbclass, and pointing the gstreamer-ti recipe at that, but I'm not sure if there's a better way.

If there are some recipes that need internal kernel sources staged for them, then it seems to me that we need both sets of kernel headers: one exported to userspace (with headers_install) and one that is not. Right? Can we agree on a standard place/manner for this?

Quoted 7 lines

Quoted 1 line

Below is my patch to get gstreamer-ti working, for illustration.

I don't really have a better suggestion, apart from adding a var in e.g. bitbake.conf to point to the userspace stuff.

We might even do the reverse, stage the full set into $kernel_dir/private and the userspace ones in $kernel_dir, that would make it more clear which recipes need internal API.

Quoted 6 lines

Anything using internal kernel headers is effectively kernel module like and should be using STAGING_DIR_KERNEL. There should be a complete set of headers available there, particularly after recent improvements to kernel.bbclass in oecore. Note that using kernel headers like this effectively makes the package machine specific since the kernel is machine specific.

When you say "_internal_ kernel headers", I assume you mean kernel headers which aren't intended for user space. But because of the "Attempt to use kernel headers from user space" warning (or rather the motivations behind the warning), I don't want to/ I can't use the exact same headers for building apps which need public kernel API as I do for building modules which use internal kernel headers.

Quoted 55 lines · Michael Jones

Quoted 47 lines · Richard Purdie

Quoted 38 lines · Koen Kooi

CC ing oe-core since we have kernel.bbclass patches there as well.

Op 18 mrt 2011, om 10:49 heeft Michael Jones het volgende geschreven:

Quoted 10 lines

Hello Koen & co.,

I recently bumped into a problem with recipes ti-dmai and gstreamer-ti when they included the kernel headers. These headers were staged by kernel.bbclass sysroot_stage_all_append() with a lot of manual copying and manipulating links and such, rather than using 'oe_runmake headers_install'. Back in October Koen explained this
(http://article.gmane.org/gmane.comp.handhelds.openembedded/37772) is because some recipes use private kernel API. The result of this with my 2.6.38 kernel

DMAI and gst-ti don't really work with anything newer than 2.6.32-psp, we're trying to get that addressed internally.

Quoted 21 lines

is that I get a warning-turned-error from linux/types.h that "Attempt to use kernel headers from user space".

ti-dmai_svn.bb hacks this (self-admittedly) by defining _EXPORTED_HEADERS_ (commit d0184be13b4879e, also from Koen). I had to modify the recipe to enable the define to actually get passed as a compile option. For gstreamer-ti, there was no such hack in place, but it was needed for the same reason.

I would think it is a common requirement for recipes to include kernel headers, and this warning has been around since 2.6.32. I got around it with gstreamer-ti by installing the headers with headers_install into a subdir of the headers directory set up currently by kernel.bbclass, and pointing the gstreamer-ti recipe at that, but I'm not sure if there's a better way.

If there are some recipes that need internal kernel sources staged for them, then it seems to me that we need both sets of kernel headers: one exported to userspace (with headers_install) and one that is not. Right? Can we agree on a standard place/manner for this?

Quoted 7 lines

Quoted 1 line

Below is my patch to get gstreamer-ti working, for illustration.

I don't really have a better suggestion, apart from adding a var in e.g. bitbake.conf to point to the userspace stuff.

We might even do the reverse, stage the full set into $kernel_dir/private and the userspace ones in $kernel_dir, that would make it more clear which recipes need internal API.

Quoted 6 lines

Anything using internal kernel headers is effectively kernel module like and should be using STAGING_DIR_KERNEL. There should be a complete set of headers available there, particularly after recent improvements to kernel.bbclass in oecore. Note that using kernel headers like this effectively makes the package machine specific since the kernel is machine specific.

Quoted 6 lines

When you say "_internal_ kernel headers", I assume you mean kernel headers which aren't intended for user space. But because of the "Attempt to use kernel headers from user space" warning (or rather the motivations behind the warning), I don't want to/ I can't use the exact same headers for building apps which need public kernel API as I do for building modules which use internal kernel headers.

Ok, so you only really have the options of:

a) Use a specific patched kernel for linux-libc-headers which has these headers in it (see below for why this is ugly)
b) Install some extra headers in "libc-headers-extras" type recipe
c) Ship default versions of the headers with your userspace and use those if shared versions don't exist. This assumes the API is stable and on its way to mainline.

I don't think this is as common a requirement as you think as most people get this kind of thing merged into the mainline kernel to try and reduce this kind of problem.

The ugliness is where you have two different arm boards you want to build, with a common optimisation/toolchain and each wants to redirect linux-libc-headers to its own "special" version. The question is then, why aren't the "special" bits in mainline.

Cheers,

Richard

Quoted 10 lines · Richard Purdie

On Fri, 2011-03-25 at 15:14 +0100, Michael Jones wrote:
Ok, so you only really have the options of:

a) Use a specific patched kernel for linux-libc-headers which has these headers in it (see below for why this is ugly)
b) Install some extra headers in "libc-headers-extras" type recipe
c) Ship default versions of the headers with your userspace and use those if shared versions don't exist. This assumes the API is stable and on its way to mainline.

Quoted 3 lines

I don't think this is as common a requirement as you think as most people get this kind of thing merged into the mainline kernel to try and reduce this kind of problem.

To clarify, it's not that I have a custom patched kernel I need to use.
I am following V4L2 development, so I am using a new kernel from those
developers. V4L2 changes do of course move upstream.

Quoted 4 lines

The ugliness is where you have two different arm boards you want to build, with a common optimisation/toolchain and each wants to redirect linux-libc-headers to its own "special" version. The question is then, why aren't the "special" bits in mainline.

OK, so here's what I'm realizing, please correct me if I'm wrong:
What I did unconventionally (ie. wrong) was to use a kernel version newer than my linux-libc-headers were. I should create a new linux-libc-headers recipe, as I had done with the kernel recipe, and build glibc and linux-libc-headers using my 2.6.38 kernel.

I only stumbled upon this because the gstreamer-ti recipes were pointing at internal kernel headers, but because these are user-space apps, they should actually be using the linux-libc-headers. Right?

Quoted 6 lines

OK, so here's what I'm realizing, please correct me if I'm wrong:
What I did unconventionally (ie. wrong) was to use a kernel version newer than my linux-libc-headers were.  I should create a new linux-libc-headers recipe, as I had done with the kernel recipe, and build glibc and linux-libc-headers using my 2.6.38 kernel.

We should *always* be using linux-libc-headers >= to the kernel version being used.

Quoted 10 lines · Richard Purdie

Quoted 6 lines

OK, so here's what I'm realizing, please correct me if I'm wrong:
What I did unconventionally (ie. wrong) was to use a kernel version newer than my linux-libc-headers were. I should create a new linux-libc-headers recipe, as I had done with the kernel recipe, and build glibc and linux-libc-headers using my 2.6.38 kernel.

We should *always* be using linux-libc-headers >= to the kernel version being used.

If you use newer kernel should work ok why is that a problem ? kernel syscalls are backward compatible
and we use oldest kernel version of like 2.6.16 for eglibc to build against so it should not be a problem
to use different versions for kernel and kernel-headers. I think your problem lies elsewhere

Quoted 11 lines · Michael Jones

Quoted 10 lines · Richard Purdie

On Fri, 2011-03-25 at 15:14 +0100, Michael Jones wrote:
Ok, so you only really have the options of:

a) Use a specific patched kernel for linux-libc-headers which has these headers in it (see below for why this is ugly)
b) Install some extra headers in "libc-headers-extras" type recipe
c) Ship default versions of the headers with your userspace and use those if shared versions don't exist. This assumes the API is stable and on its way to mainline.

Quoted 7 lines

Quoted 3 lines

I don't think this is as common a requirement as you think as most people get this kind of thing merged into the mainline kernel to try and reduce this kind of problem.

To clarify, it's not that I have a custom patched kernel I need to use.
I am following V4L2 development, so I am using a new kernel from those
developers. V4L2 changes do of course move upstream.

Ok, sorry, I was lacking context here.

Quoted 5 lines

Quoted 4 lines

The ugliness is where you have two different arm boards you want to build, with a common optimisation/toolchain and each wants to redirect linux-libc-headers to its own "special" version. The question is then, why aren't the "special" bits in mainline.

Quoted 5 lines

OK, so here's what I'm realizing, please correct me if I'm wrong:
What I did unconventionally (ie. wrong) was to use a kernel version newer than my linux-libc-headers were. I should create a new linux-libc-headers recipe, as I had done with the kernel recipe, and build glibc and linux-libc-headers using my 2.6.38 kernel.

We should *always* be using linux-libc-headers >= to the kernel version being used.

Quoted 4 lines

I only stumbled upon this because the gstreamer-ti recipes were pointing at internal kernel headers, but because these are user-space apps, they should actually be using the linux-libc-headers. Right?

Ideally, yes. I know under some circumstances, they might want to poke into internal kernel headers but that is really a design issue that needs fixing.

Cheers,

Richard