Re: Additional kconfig targets (cloneconfig, nonint_oldconfig etc)

From: Andres Salomon
Date: Tue Apr 29 2008 - 17:21:09 EST


On Tue, 29 Apr 2008 20:35:31 +0200
Sam Ravnborg <sam@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/