[OE-core] [PATCH] kernel-yocto: checksum indirect cfg and scc files

[Bruce Ashfield]

On Thu, Jul 4, 2019 at 12:36 PM <richard.purdie at linuxfoundation.org> wrote:
>
> On Thu, 2019-07-04 at 12:29 -0400, Bruce Ashfield wrote:
> > On Thu, Jul 4, 2019 at 11:18 AM Richard Purdie
> > <richard.purdie at linuxfoundation.org> wrote:
> > > On Thu, 2019-07-04 at 08:48 -0400, Bruce Ashfield wrote:
> > > > On Thu, Jul 4, 2019 at 7:02 AM Zhaolong Zhang <
> > > > zhangzl2013 at 126.com>
> > > > wrote:
> > > > > Currently, Yocto can not realize the modification of the
> > > > > cfg/scc
> > > > > files indirectly
> > > > > introduced by scc files in custom layers.
> > > > >
> > > > > Instead of introducing complicated scc parser code, this patch
> > > > > walks though
> > > > > FILESEXTRAPATHS and takes all the cfg/scc files into account
> > > > > when
> > > > > calculating
> > > > > checksums.
> > > >
> > > > There used to be a bugzilla around for this .. but I can't find
> > > > it
> > > > now.
> > > >
> > > > While the approach isn't wrong, I think it is too heavy, since it
> > > > is
> > > > looking at *all* the .scc and .cfg files that can be located in
> > > > the
> > > > search paths, not just the ones that are actually used.
> > >
> > > That isn't quite right. With the checksums its important to know if
> > > a
> > > new file appears at location X, we should reparse as it could
> > > change
> > > the outcome.
> > >
> > > We therefore have to account for files which doesn't exist as much
> > > as
> > > the ones that do.
> >
> > Maybe I'm misunderstanding what you are saying here, but these are
> > just sitting around (like unused patch files). They are not on the
> > SRC_URI and they are not necessarily used at all. Just because
> > someone
> > drops a new file in those locations, we should not be re-running the
> > meta data task.
> >
> > What that routine is currently doing is just wrong.
>
> Agreed, it is.
>
> I'm just saying that this situation isn't as simple as files exist, we
> also need to look at which files don't exist, but that would influence
> the build if they did.

Aha.

>
> The patch doesn't do that either!
>
>
> > > This doesn't work since we need to be able to predict the task hash
> > > checksum at parse time. We don't have the kern-tools available then
> > > to
> > > be able to know which ones it would actually use...
> >
> > So there's only python code allowed in those hash routines ? If so,
> > what is there is still wrong, and needs to be reworked.
>
> It has to be able to work on the information available to it at parse
> time. In reality that does mean python code. There are performance
> implications to anything too complex.

Understood.

I'll think on this for a bit. This has been something that I looked
into several times, and didn't come up with anything I really liked.
Maybe now is the time to solve the issue :)

Bruce

>
> Cheers,
>
> Richard
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II