Patchwork staging & using kernel headers

login
register
mail settings
Submitter Michael Jones
Date March 18, 2011, 9:49 a.m.
Message ID <4D832AA4.1020701@matrix-vision.de>
Download mbox | patch
Permalink /patch/1585/
State New, archived
Headers show

Comments

Michael Jones - March 18, 2011, 9:49 a.m.
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 <michael.jones@matrix-vision.de>
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(-)
Richard Purdie - March 25, 2011, 1:38 p.m.
On Fri, 2011-03-18 at 10:55 +0100, Koen Kooi wrote:
> 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:
> 
> > 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.
> 
> > 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.
> 
> 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 improvemnents 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
Michael Jones - March 25, 2011, 2:14 p.m.
Hi Richard,

On 03/25/2011 02:38 PM, Richard Purdie wrote:
> On Fri, 2011-03-18 at 10:55 +0100, Koen Kooi wrote:
>> 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:
>>
>>> 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.
>>
>>> 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.
>>
>> 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.

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.

> 
> Cheers,
> 
> Richard
> 

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
Richard Purdie - March 28, 2011, 12:42 p.m.
On Fri, 2011-03-25 at 17:02 +0100, Michael Jones wrote:
> On 03/25/2011 03:55 PM, Richard Purdie wrote:
> > 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.
> > 
> > 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.
 
> > 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.

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

> 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
Khem Raj - March 28, 2011, 4:39 p.m.
On Mon, Mar 28, 2011 at 5:42 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
>> 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

Patch

diff --git a/classes/kernel.bbclass b/classes/kernel.bbclass
index 422bcd7..6b46d51 100644
--- a/classes/kernel.bbclass
+++ b/classes/kernel.bbclass
@@ -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() {
diff --git a/recipes/ti/gstreamer-ti.inc b/recipes/ti/gstreamer-ti.inc
index 905e192..04d990f 100644
--- a/recipes/ti/gstreamer-ti.inc
+++ b/recipes/ti/gstreamer-ti.inc
@@ -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
-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