Re: [PATCH] image: allow multiple image recipes to deploy DTB_FILES

["'cedric.hombourger@siemens.com' via isar-users" <isar-users@googlegroups.com>]

On Fri, 2024-07-05 at 11:55 +0200, Cedric Hombourger wrote:
> On Fri, 2024-07-05 at 09:55 +0200, Jan Kiszka wrote:
> > On 05.07.24 09:47, Hombourger, Cedric (DI CTO FDS CES LX) wrote:
> > > On Fri, 2024-07-05 at 09:37 +0200, Jan Kiszka wrote:
> > > > On 05.07.24 09:18, 'Cedric Hombourger' via isar-users wrote:
> > > > > sstate is checking for overlapping files in DEPLOY_DIR and
> > > > > will
> > > > > raise an error when building a second image for a machine
> > > > > that
> > > > > uses DTB_FILES.
> > > > >
> > > > > Reproducer:
> > > > >   bitbake mc:phyboard-mira-bookworm:isar-image-base
> > > > >   bitbake mc:phyboard-mira-bookworm:isar-image-debug
> > > > >
> > > > > Signed-off-by: Cedric Hombourger
> > > > > <cedric.hombourger@siemens.com>
> > > > > ---
> > > > >  meta/classes/image.bbclass | 4 ++++
> > > > >  1 file changed, 4 insertions(+)
> > > > >
> > > > > diff --git a/meta/classes/image.bbclass
> > > > > b/meta/classes/image.bbclass
> > > > > index c29d9e26..8b316c83 100644
> > > > > --- a/meta/classes/image.bbclass
> > > > > +++ b/meta/classes/image.bbclass
> > > > > @@ -27,7 +27,11 @@ INITRD_IMAGE ?= ""
> > > > >  INITRD_DEPLOY_FILE = "${@ d.getVar('INITRD_IMAGE') or
> > > > > '${IMAGE_FULLNAME}-initrd.img'}"
> > > > >
> > > > >  # This defines the deployed dtbs for reuse by imagers
> > > > > +# Since we may be building several images with the same set
> > > > > of
> > > > > DTB_FILES, silent sstate
> > > > > +# overlap checks
> > > > >  DTB_FILES ?= ""
> > > > > +DEPLOY_DTB_FILES = "${@ ' '.join(['${DEPLOY_DIR_IMAGE}/' +
> > > > > os.path.basename(dtb) for dtb in
> > > > > d.getVar('DTB_FILES').split()]) }"
> > > > > +SSTATE_ALLOW_OVERLAP_FILES += "${DEPLOY_DTB_FILES}"
> > > > >
> > > > >  # Useful variables for imager implementations:
> > > > >  PP = "/home/builder/${PN}-${MACHINE}"
> > > >
> > > > There is still
> > > > https://patchwork.isar-build.org/project/isar/list/?series=1209
> > > >  pending
> > > > which looks much less risky to paper over a real conflict.
> > >
> > > Thanks Jan. I had missed this RFC patch series.
> > >
> > > That said, while it will solve the problem we are having with
> > > building
> > > multiple images with MACHINEs using DTB_FILES, it does not seem
> > > to
> > > solve the problem of a build where we are building multiple
> > > kernels
> > > (e.g. -rt and non-rt) for a given MACHINE: both kernels will be
> > > shipping the same DTB_FILES.
> >
> > Adding Uladzimir: The risk of SSTATE_ALLOW_OVERLAP_FILES, also with
> > your
> > scenario, remains that those kernels are not coming with identical
> > sources and, thus, with potentially different DTBs.
>
> Yes I cannot agree more. We probably need to look at the consumers of
> ${DEPLOY_DIR_IMAGE}/*.dtb.
>
> For instance, if the kernel was to produce a package with dtb files,
> that package could be added to the list of packages to be installed
> in
> the IMAGER sbuild environment
>
> I am happy to look into this.
>
> Once concern though is that the tree is currently broken for the
> multiple-image / multiple-kernel use-cases we talked about.
>
> If we agree that the deployment of dtb files into DEPLOY_DIR_IMAGE
> should go away (and I think it should), I would then believe that a
> work-around such as proposed herein would be acceptable (as long as
> it
> does not stay in the tree for too long).


I realize that the above patch isn't ideal but as I said our tree is
currently broken and I fear it will take some time before the solution
from Uladzimir is finalized and addresses uses-cases such as multiple
kernels for the same MACHINE (shipping the same DTB files and being
built as part of e.g. multiconfig build) and multiple images.

On my side, I won't be able to work on a different approach (avoid
using DEPLOY_DIR_IMAGE as a share) until next week (currently working
on a different patch series for linux-custom)

Should we instead use the proposed work-around in our own layers for
now?

>
> If we cannot fix or work-around this issue soon then I am afraid that
> we will see all those work-arounds in downstream layers. Thoughts?
>
> >
> > Jan
> >
> > >
> > > On our side, we happen to have that use-case on our side as well.
> > >
> > > Cedric
> > >
> > > >
> > > > Jan
> > > >
> > >
> > > --
> > > Cedric Hombourger
> > > Siemens AG
> > > http://www.siemens.com/
> >
>

--
Cedric Hombourger
Siemens AG
http://www.siemens.com/

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/d1112c0eca142565dc0389796bf89df09d9a2707.camel%40siemens.com.