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.
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)

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.

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 ...
[ message continues ]

On Tue, 29 Apr 2008 20:35:31 +0200


'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

Sounds good, I highly prefer specifying the config via env variable
--

[ message continues ]

I will try to come up with some simple algorithm to locate the file.
I guess something like:

a) Try in local dir with name supplied
b) If filname does not start with '/' try in arch/$ARCH/configs/*
c) If filname does not start with '/' try in arch/$ARCH/configs/*_defconfig

If filename is prefixed .gz unpack it

	Sam
--

[ message continues ]

/proc/.gzconfig? :-D (scnr)

--

[ message continues ]

I like this idea a lot.  I didn't like the hardcoded `.config' 13
years ago and I still

Is there any reasonable way to embed the configuration file name in the kernel
image like BSD does it?  /proc/config.gz is a good way to retrieve way to
retrieve configuration information on a running system, not so good for pushing
kernels out to a network and keeping track of the config files on the build
machine.

I don't have any way of checking this now, but can /proc files like
/proc/config.gz
be exported via NFS or the equivalent?

-sb
--

[ message continues ]

I don't know how BSD does it, but CONFIG_IKCONFIG does embed the
config image in the kernel.  It can be extracted with

---
~Randy
--

[ message continues ]

No, that's not what I meant.  Now that we have a means of specifying
a configuration file by name, it would be nice if the file name could,
for example, be appended to EXTRAVERSION.  That's all it would
take to duplicate the behavior I misdescribed.


Eg. `make K=HPxw4300.config ...' would have "-HPxw4300" appended
to EXTRAVERSION.  Maybe this doesn't make sense any more, but it
was once something I wanted very much.

-sb
--

[ message continues ]

We have "echo .foo > localversion" or CONFIG_LOCALVERSION=.foo for that.
Maybe what you would like is a variable on that make command line to
magically set CONFIG_LOCALVERSION with less typing.


Thanks,
Roland
--

[ message continues ]

You can just do:
echo "-HPxw4300" > localversion

Then it gets appended to the kernel version. While not automatic is
solves your need.

	Sam
--

[ message continues ]

Used for..?
--

[ message continues ]

1) automated - select defaults for all new symbols

If you set KCONFIG_OVERWRITECONFIG in environment, Kconfig will not break

	Sam
--

[ message continues ]

Hi,


A general comment about the intendend design:
conf.c is primarily meant as interactive tool. defconfig isn't exactly 
interactive, but is included for historical reasons as it produces the same 
output.
The patch I've seen for the last point put it into conf.c, which is the wrong 
place for it. For this sort of thing we should create a small query tool, 
which then can export all sorts of information.

If we silence the defconfig output (which IMO is a good thing, as I don't 
think anyone looked at the output seriously for a long time and the current 
behaviour has purely historical reasons), it would also open up the 
possibility to separate it from conf.c.
This also fits into an idea I'm playing with to extend the .config format like 
this:

%defaultmode: mod
CONFIG_FOO=n

Basically this could replace "make allmodconfig KCONFIG_ALLCONFIG=..." and the 
current way to produce an allmodconfig would be replaced by a dedicated 
function.

bye, Roman
--

[ message continues ]

Hi Roman.
This is work in progress...
I have created a new frontend: aconf.c that is a trimmed down version
of conf.c. aconf.c are intended to take care of all the automated configurations
such as: all*config, randconfig and the automated defconfig

In this way we have conf.c for all the interactive targets and aconf for
all the automated targets.

This is not exactly what you suggest but I thik a step in the right direction.

Comments?

	Sam

/*
 * Copyright (C) 2002 Roman Zippel <zippel@linux-m68k.org>
 * Copyright (C) 2008 Sam Ravnborg <sam@ravnborg.org>
 * Released under the terms of the GNU GPL v2.0.
 */

/*
 * Generate the automated configs
 */

#include <locale.h>
#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
#include <sys/stat.h>

#define LKC_DIRECT_LINK
#include "lkc.h"

static void check_conf(struct menu *menu);
static void conf(struct menu *menu);

enum {
	set_default,
	set_yes,
	set_mod,
	set_no,
	set_random
} input_mode;

static char *defconfig_file;

static int conf_cnt;
static struct menu *rootEntry;

/* Set strig value - it this a nop as it looks like? */
static void conf_string(struct menu *menu)
{
	struct symbol *sym = menu->sym;
	const char *def;


	if (!sym_is_changable(sym))
		return;

	if (sym_has_value(sym) && (input_mode != set_default))
		return;

	def = sym_get_string_value(sym);
	if (def)
		sym_set_string_value(sym, def);
}

static void conf_sym(struct menu *menu)
{
	struct symbol *sym = menu->sym;
	int type;
	tristate val;

	if (!sym_is_changable(sym))
		return;

	if (sym_has_value(sym) && (input_mode != set_default))
		return;

	type = sym_get_type(sym);
	switch (input_mode) {
	case set_yes:
		if (sym_tristate_within_range(sym, yes)) {
			sym_set_tristate_value(sym, yes);
			break;
		}
	/* fallthrough */
	case set_mod:
		if (type == S_TRISTATE) {
			if (sym_tristate_within_range(sym, mod)) ...
[ message continues ]

aconf is now ready to take care of defconfig, randconfig and all*config.
That leaves us with two simple tasks for conf.c:
config and oldconfig

[silentoldconfig is gone as oldconfig is 'silent' now].

aconf can take a base config for all the targets and avoids being
clever where to locate it. (Read: does not use DEFCONFIG_LIST).

I dunno if this is what you had in mind but I certainly like the result.
I understand the solution that you describe but I fail to see the
usefulness of it.
Can I request you to elaborate a bit more how you see it used.
This part I did not understand either. I am aware of the current behaviour
but do not get the "dedicated function" thing.

Thanks in advance,

	Sam
--

[ message continues ]

With the attached patch you can do:

make K=my_favourite_config defconfig

kconfig will read all config values form 'my_favourite_config'
and set all other symbols to their default value.
The output is now dense like this:
# configuration is based on 'my_favourite_config'
#
# configuration written to .config
#


The K= notations works for the usual suspects:
allnoconfig, allyesconfig, allmodconfig, randconfig and defconfig

alldefconfig with no parameters create a kernel konfiguration
with all parameters set to default.

The difference between alldefconfig and defconfig is that if
no K= parameter is specified the defconfig will try to load
one of the files specified in the defconfig list from
init/Kconfig (see DEFCONFIG_LIST)

I decided to create a new .c file to support this.
It was not strictly necessary but this allows us to
simplify conf.c a lot. I did not do so yet.

What is missing:
1) No support for .gz input file
   But aconf.sh should be easy to adjust to this

2) We hardcode that files name *_defconfig are found
   in arch/$ARCH/configs/*

3) Implement newsymbolsconfig (any better name?)
   Shall list all new symbols and shall not write
   any config

	Sam

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index fa1a7d5..3e560a4 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -47,30 +47,25 @@ update-po-config: $(obj)/kxgettext $(obj)/gconf.glade.h
 	$(Q)rm -f arch/um/Kconfig.arch
 	$(Q)rm -f $(obj)/config.pot
 
-PHONY += randconfig allyesconfig allnoconfig allmodconfig defconfig
+aconf-targets := allnoconfig allyesconfig allmodconfig alldefconfig randconfig
+PHONY += $(aconf-targets) defconfig
 
-randconfig: $(obj)/conf
-	$< -r $(Kconfig)
+$(aconf-targets): $(src)/aconf.sh $(obj)/aconf
+	$(Q)$(CONFIG_SHELL) $< $@ $(Kconfig)
 
-allyesconfig: $(obj)/conf
-	$< -y $(Kconfig)
+%_defconfig: $(src)/aconf.sh $(obj)/aconf
+	$(Q)K=arch/$(SRCARCH)/configs/$@ \
+	$(CONFIG_SHELL) $< alldefconfig $(Kconfig)
 ...
[ message continues ]

On Fri, 2 May 2008 21:09:49 +0200



Since this is aconf (automated), if we run 'make K=foo defconfig' and
'foo' doesn't contain one of the necessary values.. the build will fail,
right?


I'm not sure I see the point of #3.
--

[ message continues ]

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


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

-- 
http://www.codemonkey.org.uk
--

[ message continues ]

On Wed, 21 May 2008 17:11:39 -0400

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)

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..

--

[ message continues ]

It's actually

	make oldconfig
	[note new symbol, make decision]
	[note new symbol, make decision]
	[note new symbol, make decision]
	make


--

[ message continues ]

Been busy and got sidetracked after my first version proved broken.
Will try to look at it in the weekend.

	Sam
--

[ message continues ]

On Wed, 21 May 2008 23:47:23 +0200


Any updates on this?  I've been forced to use a workaround in the
meantime..
--

[ message continues ]

Nope. I have been busy with other stuff and need to close this first.
Pending stuff before this:

-> Simplify link of vmlinux (about to be dropped for now as I cannot solve um issue)
-> Kill need for ALTARCH in sparc (almost finished)
-> Optimize make headers_* (almost finished)

And a few more things that I cannot remember atm

	Sam
--

[ message continues ]