From: Andres Salomon <dilinger@queued.net>
To: Dave Jones <davej@codemonkey.org.uk>
Cc: Sam Ravnborg <sam@ravnborg.org>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Roland McGrath <roland@redhat.com>,
Roman Zippel <zippel@linux-m68k.org>
Subject: Re: Additional kconfig targets (cloneconfig, nonint_oldconfig etc)
Date: Wed, 21 May 2008 17:38:32 -0400 [thread overview]
Message-ID: <20080521173832.68e9d267@ephemeral> (raw)
In-Reply-To: <20080521211139.GA22591@codemonkey.org.uk>
On Wed, 21 May 2008 17:11:39 -0400
Dave Jones <davej@codemonkey.org.uk> wrote:
> On Wed, May 21, 2008 at 04:47:03PM -0400, Andres Salomon wrote:
>
> > > 3) Implement newsymbolsconfig (any better name?)
> > > Shall list all new symbols and shall not write
> > > any config
> >
> > I'm not sure I see the point of #3.
>
> It's something we've had in Fedora kernels forever, because
> when rebasing to a new upstream version the process becomes
>
> make newsymbolsconfig
> take list of symbols, and make decisions on them
> make oldconfig
>
>
Ah, I see. My process has always been:
cp arch/x86/configs/foo_defconfig .config
make oldconfig
make obvious decisions about new symbols, choose defaults if unknown
diff -u arch/x86/configs/foo_defconfig .config
figure out if any decisions or defaults are incorrect, change accordingly
make oldconfig (more decisions if there are new symbols exposed)
cp .config arch/x86/configs/foo_defconfig && commit
> without it, the process would be..
>
> make oldconfig
> note new symbol, make decision
> make oldconfig
> note a 2nd new symbol, make decision
> make oldconfig
> note a 3rd new symbol..
> make oldconfig..
> you get the idea.
>
> The way we have it isn't perfect, (adding a new symbol may unhide
> another set of new symbols), but it reduces the number of iterations
> needed dramatically.
>
> Dave
>
My build has broken again, which is why I'm inquiring about the status
of this; I'm not going to bother fixing it if my patches are never going
to end up upstream..
next prev parent reply other threads:[~2008-05-21 21:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 18:35 Additional kconfig targets (cloneconfig, nonint_oldconfig etc) Sam Ravnborg
2008-04-29 21:24 ` Andres Salomon
2008-04-30 6:35 ` Sam Ravnborg
2008-04-30 14:43 ` Jan Engelhardt
2008-04-30 10:45 ` SL Baur
2008-04-30 15:01 ` Randy Dunlap
2008-04-30 20:32 ` SL Baur
2008-04-30 20:35 ` Roland McGrath
2008-04-30 20:37 ` Sam Ravnborg
2008-04-30 14:44 ` Jan Engelhardt
2008-05-02 10:56 ` Sam Ravnborg
2008-05-01 4:40 ` Roman Zippel
2008-05-01 6:12 ` Sam Ravnborg
2008-05-03 21:49 ` Sam Ravnborg
2008-05-02 19:09 ` Sam Ravnborg
2008-05-21 20:47 ` Andres Salomon
2008-05-21 21:11 ` Dave Jones
2008-05-21 21:38 ` Andres Salomon [this message]
2008-05-22 19:06 ` Alexey Dobriyan
2008-05-21 21:47 ` Sam Ravnborg
2008-06-13 18:10 ` Andres Salomon
2008-06-13 18:14 ` Sam Ravnborg
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=20080521173832.68e9d267@ephemeral \
--to=dilinger@queued.net \
--cc=davej@codemonkey.org.uk \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=sam@ravnborg.org \
--cc=zippel@linux-m68k.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.