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

[Zhaolong Zhang]

At 2019-07-05 00:42:53, "Bruce Ashfield" <bruce.ashfield at gmail.com> wrote:
>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 :)

Thank you Bruce, I will be waiting for your solution.

Regards,
Zhaolong

>
>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