All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saul Wold <sgw@linux.intel.com>
To: Bruce Ashfield <bruce.ashfield@windriver.com>,
	 openembedded-core@lists.openembedded.org,
	richard.purdie@linuxfoundation.org
Subject: Re: [PATCH 1/2] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG
Date: Wed, 29 Nov 2017 10:24:48 -0800	[thread overview]
Message-ID: <1511979888.2714.140.camel@linux.intel.com> (raw)
In-Reply-To: <5a974b15-a273-636c-6424-b74a747276ff@windriver.com>

On Wed, 2017-11-29 at 13:13 -0500, Bruce Ashfield wrote:
> On 11/29/2017 12:52 PM, Saul Wold wrote:
> > On Wed, 2017-11-29 at 11:56 -0500, Bruce Ashfield wrote:
> > > On 11/29/2017 11:30 AM, Saul Wold wrote:
> > > > On Wed, 2017-11-29 at 09:23 -0500, Bruce Ashfield wrote:
> > > > > On 11/28/2017 10:28 PM, Saul Wold wrote:
> > > > > > When using KBUILD_DEFCONFIG, $sccs should be set to the
> > > > > > $WORKDIR/defconfig
> > > > > > regardless if it compares or is copied. Otherwise $sccs is
> > > > > > not
> > > > > > set
> > > > > > and the
> > > > > > defconfig is not found correctly.
> > > > > 
> > > > > Actually, looking at this more today, and this morning in my
> > > > > testing.
> > > > > This shouldn't be necessary .. it doesn't hurt anything
> > > > > (well,
> > > > > actually
> > > > > it could end up with two defconfigs in the variable, but that
> > > > > also
> > > > > should be ok).
> > > > > 
> > > > 
> > > > Ok, I understand, it's in find_sccs() where if you have
> > > > "defconfig"
> > > > in
> > > > the SRC_URI then with my change you could end up with two
> > > > defconfigs.
> > > > 
> > > > The problem I saw was if one just sets KBUILD_DEFCONFIG and
> > > > does
> > > > not
> > > > set any config info on the SRC_URI then it's possible for $sccs
> > > > to
> > > > be
> > > > empty, which was bad.
> > > 
> > > I took a look at the conditions again, and I can't see that
> > > path. But that doesn't mean it isn't there, is this a
> > > configuration
> > > that I can build and see myself ?
> > > 
> > 
> > Set KBUILD_DEFCONFIG to some kernel defconfig, ensure SRC_URI does
> > not
> > have any defconfig, .scc or .cfg files.  Build once that will
> > populate
> > the $WORKDIR/defconfig with vai the else path of the first if and
> > the
> > cp path in the do_kernel_metadata() code.  Build a second time and
> > the
> > $WORKDIR/defconfig exists now and the first part of the if with the
> > cmp
> > will occur and the defconfig will not be found because $sccs does
> > not
> > get set in the original code when the cmp is equal.
> 
> That's the ticket .. I didn't think of a 2nd pass through the
> build.
> 
> So with that extra assignment + a duplicate removal, it should
> be safe for all the paths.
> 
> Did you want to send a v2, or did you want me to make that tweak?
> 
If you have the tweak in mind already, might be better for you to make
it.

Thanks
 Sau!

> Either way, I'll continue testing here.
> 
> Bruce
> 
> > 
> > Sau!
> > 
> > > > 
> > > > Maybe a cleaning of multiple "defconfig" entries on $sccs is
> > > > needed?
> > > > 
> > > 
> > > Yah, regardless of my above statement, it certainly wouldn't hurt
> > > and would be a good safeguard, since two defconfigs would trigger
> > > a M x N configuration audit of options (where M and N could be
> > > in the thousands) .. and hence, take a long time.
> > > 
> > > Bruce
> > > 
> > > > Sau!
> > > > 
> > > > 
> > > > > > 
> > > > > > Part of
> > > > > > [YOCTO #12162]
> > > > > > 
> > > > > > Signed-off-by: Saul Wold <sgw@linux.intel.com>
> > > > > > ---
> > > > > >     meta/classes/kernel-yocto.bbclass | 2 +-
> > > > > >     1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/meta/classes/kernel-yocto.bbclass
> > > > > > b/meta/classes/kernel-yocto.bbclass
> > > > > > index 1d447951c49..98ec78fb768 100644
> > > > > > --- a/meta/classes/kernel-yocto.bbclass
> > > > > > +++ b/meta/classes/kernel-yocto.bbclass
> > > > > > @@ -110,8 +110,8 @@ do_kernel_metadata() {
> > > > > >     				fi
> > > > > >     			else
> > > > > >     				cp -f
> > > > > > ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}
> > > > > > ${WORKDIR}/defconfig
> > > > > > -				sccs="${WORKDIR}/defconfig
> > > > > > "
> > > > > >     			fi
> > > > > > +			sccs="${WORKDIR}/defconfig"
> > > > > 
> > > > > The test that was protecting this assignment is:
> > > > > 
> > > > >       if [ -f "${WORKDIR}/defconfig" ]; then
> > > > > 
> > > > > and then:
> > > > > 
> > > > >      cmp "${WORKDIR}/defconfig"
> > > > > "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
> > > > > 
> > > > > The only way that a defconfig can be in ${WORKDIR}/defconfig
> > > > > by
> > > > > the time this runs, is if the fetcher puts it there. Which
> > > > > means
> > > > > it is on the SRC_URI and comes from the recipe writer's
> > > > > layer.
> > > > > 
> > > > > There is existing code that already picks this up and adds it
> > > > > to the configuration queue:
> > > > > 
> > > > >            sccs="$sccs ${@" ".join(find_sccs(d))}"
> > > > > 
> > > > > So that defconfig, is already going to be picked up directly
> > > > > from the SRC_URI.
> > > > > 
> > > > > Bruce
> > > > > 
> > > > > 
> > > > > >     		else
> > > > > >     			bbfatal "A KBUILD_DEFCONFIG
> > > > > > '${KBUILD_DEFCONFIG}' was specified, but not present in the
> > > > > > source
> > > > > > tree"
> > > > > >     		fi
> > > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> 
> 


  reply	other threads:[~2017-11-29 18:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-29  3:28 [PATCH 1/2] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG Saul Wold
2017-11-29  3:28 ` [PATCH 2/2] kernel-yocto: Stop the build if defconfig is missing Saul Wold
2017-11-29  3:46 ` [PATCH 1/2] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG Bruce Ashfield
2017-11-29 14:23 ` Bruce Ashfield
2017-11-29 16:30   ` Saul Wold
2017-11-29 16:56     ` Bruce Ashfield
2017-11-29 17:52       ` Saul Wold
2017-11-29 18:13         ` Bruce Ashfield
2017-11-29 18:24           ` Saul Wold [this message]
2017-12-01  5:38             ` Bruce Ashfield

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=1511979888.2714.140.camel@linux.intel.com \
    --to=sgw@linux.intel.com \
    --cc=bruce.ashfield@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.