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

[Bruce Ashfield]

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.

>
> > I do have some old code from the existing bugzilla that I can try and
> > locate. The right approach is to have the kern-tools emit the list of
> > files, since that's where we know the includes, etc, and what is
> > actually going to be used. What you have will also conflict a bit
> > with
> > some changes that I'm making to tweak the config handling.
> >
> > Since I can't find the old bugzilla, can you open a new one, put the
> > patch there and I can find the code to dump the list of files from
> > the tools.
>
> 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.

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