Re: staging & using kernel headers

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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