[OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard.purdie at linuxfoundation.org]

On Mon, 2018-09-24 at 09:43 -0400, Bruce Ashfield wrote:
> > On Mon, 2018-09-24 at 13:20 +0000, Mikko.Rapeli at bmw.de wrote:
> > > On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> > > > On Mon, 2018-09-24 at 12:19 +0000, Mikko.Rapeli at bmw.de wrote:
> > > > > > That was one old way, but not the only. And not for
> > > > > > exposing
> > > > > > non
> > > > > > uapi
> > > > > > headers.
> > > > > 
> > > > > What other ways exist?
> > > > > 
> > > > > I don't care how, but I must export custom kernel specific
> > > > > headers
> > > > > and
> > > > > other files to other recipes in a build in ways which are
> > > > > compatible
> > > > > with
> > > > > yocto upstream.
> > > > > 
> > > > > I have not seen any documented ways for this.
> > > > 
> > > > It may not be documented, perhaps because its actually very
> > > > simple.
> > > > 
> > > > Any recipe can expose headers into the recipe sysroot, they
> > > > simply
> > > > install them where needed in do_install as normal.
> > > > 
> > > > So all you need is a recipe which installs the right headers
> > > > and
> > > > then
> > > > you DEPEND on that recipe. Where that recipe gets the headers
> > > > isn't
> > > > relevant.
> > > 
> > > No, this does not work on sumo. My patch is needed for this to
> > > work.
> > > 
> > > Without my patch, users of kernel.bbclass have zero files in
> > > tmp/sysroot-components even if they install extra files and extra
> > > header only binary packages.
> > > 
> > > A generated image or SDK will have the files if the binary
> > > package is
> > > installed but sysroot not.
> > 
> > I was replying from the perspective of how this should work in
> > general.
> > I agree that for this to work with a kernel recipe we do need the
> > change that started this thread and that is probably a reasonable
> > thing
> > to do.
> 
> We have a Yocto bugzilla that can be closed if you are ok with the
> approach.
> 
> To answer the other question about what I've done (and proposed
> before) was
> to maintain the kernel.bbclass protections, all call the staging
> routines myself.
> 
> i.e.
> 
> do_install_append() {
>         make headers_install
> INSTALL_HDR_PATH=${D}${KERNEL_ALT_HEADER_DIR}
> 
>         # remove export artifacts
>         find ${D}${KERNEL_ALT_HEADER_DIR} -name .install -exec rm {}
> \;
>         find ${D}${KERNEL_ALT_HEADER_DIR} -name ..install.cmd -exec
> rm {} \;
> }
> 
> sysroot_stage_all_append() {
>     sysroot_stage_dir ${D}${KERNEL_ALT_HEADER_DIR}
> ${SYSROOT_DESTDIR}${KERNEL_ALT_HEADER_DIR}
> }
> 
> And that works to get things exported.

I'm fine with this approach, I'm kind of surprised anyone thinks
otherwise as I've always assumed this was what people were doing!

I'd propose that:

a) We document the above approach. I prefer it to Mikko's patch since
it doesn't mess with the blacklist and installs exactly what the recipe
wants to install which is how we normally write recipes.
b) To document it, I suggest a comment/reference in kernel.bbclass and
we add something somewhere in the manual. Adding Scott Rifenbark to cc
so he can help us sort this out.
c) Close out the bug Bruce mentions with this documentation as a
reference.

I think this means we probably don't need Mikko's patch and it is
mainly a documentation issue?

In case people wonder, the thing I really care about in this is people
are not patching linux-libc-headers. That warning still very much
applies.

I did also check and the code in question was introduced by Bruce:
http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/kernel.bb
class?id=46cdaf1c7bc597735d926af6a46f9483f7e57ce5 3.5 years ago, there
were not reasons we were not installing headers there afaict, we have
just been assuming people append to sysroot_stage_all.

Cheers,

Richard