Message-ID: <20080429172402.14d7d40b@ephemeral>
Date:	Tue, 29 Apr 2008 17:24:02 -0400
From:	Andres Salomon <dilinger@...ued.net>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	linux-kbuild <linux-kbuild@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Dave Jones <davej@...emonkey.org.uk>,
	Roland McGrath <roland@...hat.com>
Subject: Re: Additional kconfig targets (cloneconfig, nonint_oldconfig etc)

On Tue, 29 Apr 2008 20:35:31 +0200
Sam Ravnborg <sam@...nborg.org> wrote:

> Recently there has been request for a number of new
> kconfig related targets.
> 
> In general it boils down to the following:
> 
> We need to be flexible in what configuration
> we start out from and how we apply it.
> 
> We need to be able to apply it in following ways:
> 1) automated - select defaults for all new symbols
>    => It is used for "make defconfig, make *_defconfig" today
> 
> 2) interactive - asking user for all new symbols
>    and error out if stdin is redirected
> 
> 3) list unknown - list all new symbols and do not
>    create a new config
> 
> With oldconfig today we have two modes:
> -> One mode where we are very chatty and show
>    all output.
> -> And the 'silent' mode where we only start being
>    chatty when we see a new symbol.
> 
> I plan to drop the 'very chatty' mode as I
> do not see it usefull.

I'd certainly agree with that.

> So in essense 'make oldconfig' and 'make silentoldconfig'
> become equal.
> 
> The commands we have today for kconfig is:
> 
> # Command line variants
> make oldconfig
> make silentoldconfig
> make defconfig
> make XXX_defconfig
> 
> (The other frontends are left out on purpose).
> The challenge here is to come up with a syntax that
> allows us to select between the three behaviours,
> while keeping backward compatibility.
> 
> The best suggestion I have so far is to say that:
> a) if defconfig is specified then we use method 1)
> b) if oldconfig is specified then we use method 2)
> c) if newconfig is specified then we use method 3)
> 

'newconfig' sounds to me like you're creating a new config; the exact
opposite of what it does.  I'd suggest 'listnewconfig' or some such thing.
Then again, 'defconfig' and 'oldconfig' are primarily what I care about,
as I haven't been in a situation where I would have found method 3) to
be useful.

> And we add support for a new 'commandline' parameter
> 'K' so I can say:
> 
> make K=/proc/config.gz defconfig
> make K=i386_defconfig  defconfig
> make K=i386_defconfig  oldconfig
> make K=/proc/config.gz newconfig
> 
> So K is used to specify what config file we use
> to start out from.

Sounds good, I highly prefer specifying the config via env variable
rather than embedded in the target (ie, 'make olpc_defconfig').

> 
> Care should be taken to keep the known good
> targets working as before.
> 
> Andres Salomon already did some preparational work
> for this but I need to find a good way to handle the K=
> parameter.
> Dave J also posted patches that is useful for 'newconfig'.
> 
> But I wanted to ask for opinions before diving into
> implmenting this.
> 
> 	Sam
> 
> [Random notes..]
> 
> # Enviroment variables affecting kconfig
> KCONFIG_ALLCONFIG
> KCONFIG_NOSILENTUPDATE
> KCONFIG_CONFIG
> KCONFIG_OVERWRITECONFIG
> KCONFIG_NOTIMESTAMP
> KCONFIG_AUTOCONFIG
> KCONFIG_AUTOHEADER
> 
> #input files (aparts from the mandatory ones)
> all.config
> allno.config
> allmod.config
> allyes.config
> allrandom.config
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists