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