Re: staging & using kernel headers

Re: staging & using kernel headers

[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:

> 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.

regards,

Koen

> 
> -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(-)
> 
> 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
> -- 
> 1.7.4.1
> 
> 
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: staging & using kernel headers

[Richard Purdie]

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

Re: staging & using kernel headers

[Michael Jones]

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

Re: staging & using kernel headers

[Richard Purdie]

On Fri, 2011-03-25 at 15:14 +0100, Michael Jones wrote:
> 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.

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

Re: staging & using kernel headers

[Michael Jones]

On 03/25/2011 03:55 PM, Richard Purdie wrote:
> On Fri, 2011-03-25 at 15:14 +0100, Michael Jones wrote:
>> 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.
> 
> 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.

> 
> 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?

thanks for the discussion,
Michael

> 
> Cheers,
> 
> Richard
> 


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

Re: [oe] staging & using kernel headers

[Richard Purdie]

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

Re: [oe] staging & using kernel headers

[Khem Raj]

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

Re: [oe] staging & using kernel headers

[Michael Jones]

On 03/28/2011 06:39 PM, Khem Raj wrote:
> 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
> 

There is a kernel interface in the V4L2 development tree that is being
introduced in 2.6.39 (but which in my local branch is patched on top of
2.6.38).  The problem I kicked off this thread with was due to ti-dmai
and gstreamer-ti _directly_ using the headers from this kernel, which
since 2.6.32 gives a warning for doing so.

Of course, I'm using the newer kernel for a reason, which is to use the
new kernel API.  So I need to use the headers from my local development
kernel (built by an OE recipe) when building that application, which I'm
now writing the recipe for.  I thought at first that userspace apps were
automatically built against the headers derived from the kernel being
used (which is what the ti recipes do, but incorrectly).  During this
thread I realized that linux-libc-headers is a separate recipe intended
for supplying user headers.

I suppose I will use the method for my V4L2 app that I kicked off this
thread with- staging the development kernel's headers with make_install
somewhere which can be used by my app.  As Richard pointed out earlier
in this thread, making the package dependent on the kernel makes the
package machine dependent.  This is OK for this package, but I still
want all other apps to be Angstrom-generic apps, so I don't want to
change linux-libc-headers to use my kernel headers after all.

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

Re: [oe] staging & using kernel headers

[Michael Jones]

Sorry for the delay, I overlooked the last 2 replies because I was no
longer in to: or cc:  :(

On 03/28/2011 02:42 PM, Richard Purdie wrote:
> 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.

Isn't it the other way around?  Steffen Sledz had the opposite problem
as me in Feb
(http://www.mail-archive.com/openembedded-devel%40lists.openembedded.org/msg16022.html)
because he's using a kernel older than the linux-libc-headers.  He
quotes the kernel doc: "This means that a program built against a C
library using older kernel headers should run on a newer 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?
> 
> 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
> 

-Michael


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