From: richard.purdie@linuxfoundation.org
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] kernel-yocto: checksum indirect cfg and scc files
Date: Thu, 04 Jul 2019 17:36:03 +0100 [thread overview]
Message-ID: <64ce05dd1d970dc5b0390d57b4c9b75c44f405f4.camel@linuxfoundation.org> (raw)
In-Reply-To: <CADkTA4NQr2LkB3k32Djxn-zX0m2jSCLz_yEjN7pPPzdNoJMaYA@mail.gmail.com>
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@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@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.
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.
Cheers,
Richard
next prev parent reply other threads:[~2019-07-04 16:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-04 10:29 [PATCH] kernel-yocto: checksum indirect cfg and scc files Zhaolong Zhang
2019-07-04 12:48 ` Bruce Ashfield
2019-07-04 15:18 ` Richard Purdie
2019-07-04 16:29 ` Bruce Ashfield
2019-07-04 16:36 ` richard.purdie [this message]
2019-07-04 16:42 ` Bruce Ashfield
2019-07-05 7:49 ` Zhaolong Zhang
2019-07-05 17:11 ` Robert Berger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64ce05dd1d970dc5b0390d57b4c9b75c44f405f4.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=bruce.ashfield@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox