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

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

[Mikko Rapeli]

This change enables kernel recipes to share files with other
recipes. Firmware, modules and kernel-depmod are still not shared
since according to git history they cause problems with multiarch,
but all others are allowed. Examples of shared files are
kernel version and recipe specific headers and scripts which
are not needed by common linux-libc-headers to bootstrap glibc.

For example, if a kernel recipe wants to share headers, it can do:

PACKAGES =+ "${PN}-headers"

do_install_append() {
    install -d "${D}${includedir}/${PN}"
    oe_runmake INSTALL_HDR_PATH="${D}${includedir}/${PN}" headers_install
}

FILES_${PN}-headers = "\
                      ${includedir}/${PN}/* \
                      "

Users can find the headers from ${includedir}/${PN} and they don't conflict
with the generic linux-libc-headers which are used to boostrap userspace.

Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
---
 meta/classes/kernel.bbclass | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index bfb4243..acf9c2c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -487,10 +487,14 @@ do_shared_workdir () {
 	fi
 }
 
-# We don't need to stage anything, not the modules/firmware since those would clash with linux-firmware
-sysroot_stage_all () {
-	:
-}
+# We don't need to stage modules/firmware since those would clash with linux-firmware, but
+# kernel recipes can still expose kernel version specific headers or scripts to userspace
+# sysroot.
+SYSROOT_DIRS_BLACKLIST_append += "\
+    ${datadir}/kernel-depmod \
+    ${base_libdir}/modules \
+    ${base_libdir}/firmware \
+"
 
 KERNEL_CONFIG_COMMAND ?= "oe_runmake_call -C ${S} CC="${KERNEL_CC}" O=${B} oldnoconfig"
 
-- 
1.9.1

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Bruce Ashfield]

On Fri, Sep 21, 2018 at 7:49 AM, Mikko Rapeli <mikko.rapeli@bmw.de> wrote:
> This change enables kernel recipes to share files with other
> recipes. Firmware, modules and kernel-depmod are still not shared
> since according to git history they cause problems with multiarch,
> but all others are allowed. Examples of shared files are
> kernel version and recipe specific headers and scripts which
> are not needed by common linux-libc-headers to bootstrap glibc.
>
> For example, if a kernel recipe wants to share headers, it can do:
>
> PACKAGES =+ "${PN}-headers"
>
> do_install_append() {
>     install -d "${D}${includedir}/${PN}"
>     oe_runmake INSTALL_HDR_PATH="${D}${includedir}/${PN}" headers_install
> }

This is what I've always done in the past (and in fact, there's an
open Yocto bug
to track this), but I haven't actually needed to do what you are
modifying in the
bbclass itself.

If you call the sysroot stage routines directly in that
install_append, are you really
not seeing the files appear in the recipe's sysroot ?

Have you confirmed that we get a warning/error from bitbake about
conflicting files
from multiple recipes if someone doesn't know to use a custom path for their
headers ? That has always been the main concern about allowing something like
this.

Cheers,

Bruce

>
> FILES_${PN}-headers = "\
>                       ${includedir}/${PN}/* \
>                       "
>
> Users can find the headers from ${includedir}/${PN} and they don't conflict
> with the generic linux-libc-headers which are used to boostrap userspace.
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
> ---
>  meta/classes/kernel.bbclass | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index bfb4243..acf9c2c 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -487,10 +487,14 @@ do_shared_workdir () {
>         fi
>  }
>
> -# We don't need to stage anything, not the modules/firmware since those would clash with linux-firmware
> -sysroot_stage_all () {
> -       :
> -}
> +# We don't need to stage modules/firmware since those would clash with linux-firmware, but
> +# kernel recipes can still expose kernel version specific headers or scripts to userspace
> +# sysroot.
> +SYSROOT_DIRS_BLACKLIST_append += "\
> +    ${datadir}/kernel-depmod \
> +    ${base_libdir}/modules \
> +    ${base_libdir}/firmware \
> +"
>
>  KERNEL_CONFIG_COMMAND ?= "oe_runmake_call -C ${S} CC="${KERNEL_CC}" O=${B} oldnoconfig"
>
> --
> 1.9.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

> On Fri, Sep 21, 2018 at 7:49 AM, Mikko Rapeli <mikko.rapeli at bmw.de> wrote:
> > This change enables kernel recipes to share files with other
> > recipes. Firmware, modules and kernel-depmod are still not shared
> > since according to git history they cause problems with multiarch,
> > but all others are allowed. Examples of shared files are
> > kernel version and recipe specific headers and scripts which
> > are not needed by common linux-libc-headers to bootstrap glibc.
> >
> > For example, if a kernel recipe wants to share headers, it can do:
> >
> > PACKAGES =+ "${PN}-headers"
> >
> > do_install_append() {
> >     install -d "${D}${includedir}/${PN}"
> >     oe_runmake INSTALL_HDR_PATH="${D}${includedir}/${PN}" headers_install
> }
> 
> This is what I've always done in the past (and in fact, there's an
> open Yocto bug
> to track this), but I haven't actually needed to do what you are
> modifying in the
> bbclass itself.

Without this patch, users of kernel.bbclass can provide the headers etc packages,
but other recipes can never see the files in their sysroot even if they depend
on the kernel recipe because kernel.bbclass has disabled sysroot_stage_all()
completely.

The recipes could define their own sysroot_stage_all() but I don't see
why kernel would be that special and why all of their installed files should
be excluded from build sysroots by default.

The old way to do this was to fork linux-libc-headers for the custom kernel
but now it has a big fat warning to not do this, but exposing header etc
files to other recipes to build against was still not resolved.

With this patch the kernel recipe can just install the files needed and
users can see them unless they are filtered.

> If you call the sysroot stage routines directly in that
> install_append, are you really
> not seeing the files appear in the recipe's sysroot ?

Of course this can be done but why on earth is kernel so special that
it's installed files are not visible in sysroots by default?

If certain files are problematic, they can be filtered out from the
sysroot like my patch tries to do.

> Have you confirmed that we get a warning/error from bitbake about
> conflicting files
> from multiple recipes if someone doesn't know to use a custom path for their
> headers ? That has always been the main concern about allowing something like
> this.

No, but I do rely on this with other recipes as well. At least I know that
conflicting files warning will fail image and SDK generation.

I would expect that recipe specific sysroots don't allow conflicting files.

-Mikko

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Bruce Ashfield]

On Mon, Sep 24, 2018 at 3:25 AM,  <Mikko.Rapeli@bmw.de> wrote:
>> On Fri, Sep 21, 2018 at 7:49 AM, Mikko Rapeli <mikko.rapeli at bmw.de> wrote:
>> > This change enables kernel recipes to share files with other
>> > recipes. Firmware, modules and kernel-depmod are still not shared
>> > since according to git history they cause problems with multiarch,
>> > but all others are allowed. Examples of shared files are
>> > kernel version and recipe specific headers and scripts which
>> > are not needed by common linux-libc-headers to bootstrap glibc.
>> >
>> > For example, if a kernel recipe wants to share headers, it can do:
>> >
>> > PACKAGES =+ "${PN}-headers"
>> >
>> > do_install_append() {
>> >     install -d "${D}${includedir}/${PN}"
>> >     oe_runmake INSTALL_HDR_PATH="${D}${includedir}/${PN}" headers_install
>> }
>>
>> This is what I've always done in the past (and in fact, there's an
>> open Yocto bug
>> to track this), but I haven't actually needed to do what you are
>> modifying in the
>> bbclass itself.
>
> Without this patch, users of kernel.bbclass can provide the headers etc packages,
> but other recipes can never see the files in their sysroot even if they depend
> on the kernel recipe because kernel.bbclass has disabled sysroot_stage_all()
> completely.

It doesn't need to be in a class, any kernel recipe can create a task to
do this. The class implementation isn't special in this manner.

>
> The recipes could define their own sysroot_stage_all() but I don't see
> why kernel would be that special and why all of their installed files should
> be excluded from build sysroots by default.

Exactly. It is because of the ability to clobber the libc-headers that is is
special.

>
> The old way to do this was to fork linux-libc-headers for the custom kernel
> but now it has a big fat warning to not do this, but exposing header etc
> files to other recipes to build against was still not resolved.

That was one old way, but not the only. And not for exposing non uapi
headers.

>
> With this patch the kernel recipe can just install the files needed and
> users can see them unless they are filtered.

And as the warning points out, risk the libc-interface, which has caused
many problems in the past .. and problems that are hard to detect and
dig out at runtime.

>
>> If you call the sysroot stage routines directly in that
>> install_append, are you really
>> not seeing the files appear in the recipe's sysroot ?
>
> Of course this can be done but why on earth is kernel so special that
> it's installed files are not visible in sysroots by default?

because they clobber the uapi libc-headers :D

>
> If certain files are problematic, they can be filtered out from the
> sysroot like my patch tries to do.

Or we could catch that the clobbering is happening, and not let it happen.

>
>> Have you confirmed that we get a warning/error from bitbake about
>> conflicting files
>> from multiple recipes if someone doesn't know to use a custom path for their
>> headers ? That has always been the main concern about allowing something like
>> this.
>
> No, but I do rely on this with other recipes as well. At least I know that
> conflicting files warning will fail image and SDK generation.

For something that is being proposed as a general purpose addition to
the core, it would probably be a good idea to test these extra cases.

>
> I would expect that recipe specific sysroots don't allow conflicting files.

Agreed, but definitely worth testing and logging. That way the change
won't be blamed for causing issues later.

Bruce

>
> -Mikko



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 08:12:53AM -0400, Bruce Ashfield wrote:
> On Mon, Sep 24, 2018 at 3:25 AM,  <Mikko.Rapeli@bmw.de> wrote:
> >> On Fri, Sep 21, 2018 at 7:49 AM, Mikko Rapeli <mikko.rapeli at bmw.de> wrote:
> >> > This change enables kernel recipes to share files with other
> >> > recipes. Firmware, modules and kernel-depmod are still not shared
> >> > since according to git history they cause problems with multiarch,
> >> > but all others are allowed. Examples of shared files are
> >> > kernel version and recipe specific headers and scripts which
> >> > are not needed by common linux-libc-headers to bootstrap glibc.
> >> >
> >> > For example, if a kernel recipe wants to share headers, it can do:
> >> >
> >> > PACKAGES =+ "${PN}-headers"
> >> >
> >> > do_install_append() {
> >> >     install -d "${D}${includedir}/${PN}"
> >> >     oe_runmake INSTALL_HDR_PATH="${D}${includedir}/${PN}" headers_install
> >> }
> >>
> >> This is what I've always done in the past (and in fact, there's an
> >> open Yocto bug
> >> to track this), but I haven't actually needed to do what you are
> >> modifying in the
> >> bbclass itself.
> >
> > Without this patch, users of kernel.bbclass can provide the headers etc packages,
> > but other recipes can never see the files in their sysroot even if they depend
> > on the kernel recipe because kernel.bbclass has disabled sysroot_stage_all()
> > completely.
> 
> It doesn't need to be in a class, any kernel recipe can create a task to
> do this. The class implementation isn't special in this manner.
> 
> >
> > The recipes could define their own sysroot_stage_all() but I don't see
> > why kernel would be that special and why all of their installed files should
> > be excluded from build sysroots by default.
> 
> Exactly. It is because of the ability to clobber the libc-headers that is is
> special.
> 
> >
> > The old way to do this was to fork linux-libc-headers for the custom kernel
> > but now it has a big fat warning to not do this, but exposing header etc
> > files to other recipes to build against was still not resolved.
> 
> 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.

> >
> > With this patch the kernel recipe can just install the files needed and
> > users can see them unless they are filtered.
> 
> And as the warning points out, risk the libc-interface, which has caused
> many problems in the past .. and problems that are hard to detect and
> dig out at runtime.
> 
> >
> >> If you call the sysroot stage routines directly in that
> >> install_append, are you really
> >> not seeing the files appear in the recipe's sysroot ?
> >
> > Of course this can be done but why on earth is kernel so special that
> > it's installed files are not visible in sysroots by default?
> 
> because they clobber the uapi libc-headers :D
> 
> >
> > If certain files are problematic, they can be filtered out from the
> > sysroot like my patch tries to do.
> 
> Or we could catch that the clobbering is happening, and not let it happen.
> 
> >
> >> Have you confirmed that we get a warning/error from bitbake about
> >> conflicting files
> >> from multiple recipes if someone doesn't know to use a custom path for their
> >> headers ? That has always been the main concern about allowing something like
> >> this.
> >
> > No, but I do rely on this with other recipes as well. At least I know that
> > conflicting files warning will fail image and SDK generation.
> 
> For something that is being proposed as a general purpose addition to
> the core, it would probably be a good idea to test these extra cases.
> 
> >
> > I would expect that recipe specific sysroots don't allow conflicting files.
> 
> Agreed, but definitely worth testing and logging. That way the change
> won't be blamed for causing issues later.

If files from a recipe can replace files from another recipe when preparing
recipe specific sysroot we have bigger problems than just the kernel.

I can try test this out with the kernel recipe though.

-Mikko

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Richard Purdie]

On Mon, 2018-09-24 at 12:19 +0000, Mikko.Rapeli@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.

Cheers,

Richard

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> On Mon, 2018-09-24 at 12:19 +0000, Mikko.Rapeli@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.

-Mikko

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard.purdie]

On Mon, 2018-09-24 at 13:20 +0000, Mikko.Rapeli@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@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.

Cheers,

Richard

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie@linuxfoundation.org wrote:
> On Mon, 2018-09-24 at 13:20 +0000, Mikko.Rapeli@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@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.

Good, then my patch is not going in the wrong direction.

Remaining problem is if file overwrites will be detected or not so that
accidental overrides of files in linux-libc-headers from kernel recipes
should not be possible...

-Mikko

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard.purdie]

On Mon, 2018-09-24 at 13:42 +0000, Mikko.Rapeli@bmw.de wrote:
> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie@linuxfoundat
> ion.org wrote:
> > 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.
> 
> Good, then my patch is not going in the wrong direction.
> 
> Remaining problem is if file overwrites will be detected or not so
> that
> accidental overrides of files in linux-libc-headers from kernel
> recipes
> should not be possible...

That is a general problem and the core sstate code shouldn't let that
happen these days so I think that is already covered?

Cheers,

Richard

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Bruce Ashfield]

On Mon, Sep 24, 2018 at 9:44 AM,  <richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2018-09-24 at 13:42 +0000, Mikko.Rapeli@bmw.de wrote:
>> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie@linuxfoundat
>> ion.org wrote:
>> > 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.
>>
>> Good, then my patch is not going in the wrong direction.
>>
>> Remaining problem is if file overwrites will be detected or not so
>> that
>> accidental overrides of files in linux-libc-headers from kernel
>> recipes
>> should not be possible...
>
> That is a general problem and the core sstate code shouldn't let that
> happen these days so I think that is already covered?

Yep, it should be covered. I was just looking for confirmation.

Can everyone have a look at:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305

And confirm that it can be closed by this .. ? I suggested my approach
in that bug, but it
never went anywhere at the time.

Bruce

>
> Cheers,
>
> Richard



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Bruce Ashfield]

On Mon, Sep 24, 2018 at 9:46 AM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Mon, Sep 24, 2018 at 9:44 AM,  <richard.purdie@linuxfoundation.org> wrote:
>> On Mon, 2018-09-24 at 13:42 +0000, Mikko.Rapeli@bmw.de wrote:
>>> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie@linuxfoundat
>>> ion.org wrote:
>>> > 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.
>>>
>>> Good, then my patch is not going in the wrong direction.
>>>
>>> Remaining problem is if file overwrites will be detected or not so
>>> that
>>> accidental overrides of files in linux-libc-headers from kernel
>>> recipes
>>> should not be possible...
>>
>> That is a general problem and the core sstate code shouldn't let that
>> happen these days so I think that is already covered?
>
> Yep, it should be covered. I was just looking for confirmation.
>
> Can everyone have a look at:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305
>
> And confirm that it can be closed by this .. ? I suggested my approach
> in that bug, but it
> never went anywhere at the time.

Sorry for all the email, I hit send a bit too soon.

The only issue that would remain for that bug is that there's no
standard/default location for those exported extra headers, and it
is up to the kernel recipe packager to make sure that their recipes
know where to look for them.

I'm not convinced there has to be a standard location for them, so
I'll all for closing that old bug.

Bruce

>
> Bruce
>
>>
>> Cheers,
>>
>> Richard
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 09:48:26AM -0400, Bruce Ashfield wrote:
> On Mon, Sep 24, 2018 at 9:46 AM, Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
> > On Mon, Sep 24, 2018 at 9:44 AM,  <richard.purdie@linuxfoundation.org> wrote:
> >> On Mon, 2018-09-24 at 13:42 +0000, Mikko.Rapeli@bmw.de wrote:
> >>> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie@linuxfoundat
> >>> ion.org wrote:
> >>> > 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.
> >>>
> >>> Good, then my patch is not going in the wrong direction.
> >>>
> >>> Remaining problem is if file overwrites will be detected or not so
> >>> that
> >>> accidental overrides of files in linux-libc-headers from kernel
> >>> recipes
> >>> should not be possible...
> >>
> >> That is a general problem and the core sstate code shouldn't let that
> >> happen these days so I think that is already covered?
> >
> > Yep, it should be covered. I was just looking for confirmation.
> >
> > Can everyone have a look at:
> >
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305
> >
> > And confirm that it can be closed by this .. ? I suggested my approach
> > in that bug, but it
> > never went anywhere at the time.
> 
> Sorry for all the email, I hit send a bit too soon.
> 
> The only issue that would remain for that bug is that there's no
> standard/default location for those exported extra headers, and it
> is up to the kernel recipe packager to make sure that their recipes
> know where to look for them.
> 
> I'm not convinced there has to be a standard location for them, so
> I'll all for closing that old bug.

It would be nice for kernel.bbclass to help creating the custom kernel specific
-dev package with headers, and it would be nice to have a kernel-headers.bbclass
to help users to find them by adding the path to default include paths for
the recipe. And while writing wishlists, would be nice to support multiple
kernel recipes per machine. We forced a second recipe by cloning the
kernel and other bbclasses and added a different prefix...

But I'm ok with my patch and doing other things per recipe for now.

-Mikko

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard.purdie]

On Mon, 2018-09-24 at 13:55 +0000, Mikko.Rapeli@bmw.de wrote:
> It would be nice for kernel.bbclass to help creating the custom
> kernel specific -dev package with headers, and it would be nice to
> have a kernel-headers.bbclass to help users to find them by adding
> the path to default include paths for the recipe. And while writing
> wishlists, would be nice to support multiple kernel recipes per
> machine. We forced a second recipe by cloning the kernel and other
> bbclasses and added a different prefix...

FWIW multiple kernels is a long desired feature and I'd be happy to see
a patch which allows the kernel classes to be configured to build a
second kernel with a different package namespace.

The kernel-headers class may be ok too and simplify the documentation
process, particularly if the subdir to put the headers in was
configurable.

Cheers,

Richard

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Bruce Ashfield]

On Mon, Sep 24, 2018 at 9:38 AM,  <richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2018-09-24 at 13:20 +0000, Mikko.Rapeli@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@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.

Bruce

>
> Cheers,
>
> Richard
>
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard.purdie]

On Mon, 2018-09-24 at 09:43 -0400, Bruce Ashfield wrote:
> > On Mon, 2018-09-24 at 13:20 +0000, Mikko.Rapeli@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@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

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 02:56:49PM +0100, richard.purdie@linuxfoundation.org wrote:
> On Mon, 2018-09-24 at 09:43 -0400, Bruce Ashfield wrote:
> > > On Mon, 2018-09-24 at 13:20 +0000, Mikko.Rapeli@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@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?

My only complaint is that it's not obvious in a kernel recipe that
more than do_install() is needed to export files to sysroot.
It's easy to miss the sysroot_stage_all_append() step.

Overwriting files from kernel recipe fails when they are used to prepare
sysroots for user recipes, but not when the kernel recipe is build:

ERROR: linux-image-1.0.0-r21 do_prepare_recipe_sysroot: The file /usr/include/scsi/scsi_bsg_fc.h is installed by both linux-libc-headers and linux, aborting
ERROR: linux-image-1.0.0-r21 do_prepare_recipe_sysroot: Function failed: extend_recipe_sysroot

In this case linux recipe added kernel specific headers to /usr/include
which conflict with linux-libc-headers and this was only cought when building
the kernel image.

-Mikko

Re: [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard.purdie]

On Mon, 2018-09-24 at 14:19 +0000, Mikko.Rapeli@bmw.de wrote:
> My only complaint is that it's not obvious in a kernel recipe that
> more than do_install() is needed to export files to sysroot.
> It's easy to miss the sysroot_stage_all_append() step.

I think that becomes a documentation problem. The bbclass helper may
also help?

> Overwriting files from kernel recipe fails when they are used to
> prepare sysroots for user recipes, but not when the kernel recipe is
> build:
> 
> ERROR: linux-image-1.0.0-r21 do_prepare_recipe_sysroot: The file
> /usr/include/scsi/scsi_bsg_fc.h is installed by both linux-libc-
> headers and linux, aborting
> ERROR: linux-image-1.0.0-r21 do_prepare_recipe_sysroot: Function
> failed: extend_recipe_sysroot
> 
> In this case linux recipe added kernel specific headers to
> /usr/include which conflict with linux-libc-headers and this was only
> cought when building the kernel image.

That is true, not sure how exactly we'd detect that earlier either (in
a way which doesn't kill performance or involve special cases). I'm
open to ideas, documentation is the main tool I think we have here.

Cheers,

Richard