[oe] [OE-core] 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