Quick and dirty miniconfig howto, with feature suggestions.

Quick and dirty miniconfig howto, with feature suggestions.

[Rob Landley]

--- What is a miniconfig?

A new feature of 2.6.15 lets you use miniature configuration files, listing 
just the symbols you want to enable and letting the configurator enable any 
dependencies to give you a valid configuration.

To make it work, create a mini.config file and run allnoconfig (to create 
a .config file with all unspecified symbols switched off) with the extra 
argument "KCONFIG_ALLCONFIG=mini.config".

--- Advantages of miniconfigs

Miniconfigs have several advantages over conventional configuration files:

 * They're portable between versions.  A miniconfig from linux 2.6.15 will
   probably build an equivalent 2.6.16 kernel.

 * It's easy to see exactly what features have been specified.

 * Miniconfigs are flexible and human editable, while generated .config files
   are brittle and easy to break if you try to edit them.  (And if you
   redirect the output > /dev/null so you just see stderr, it'll show you
   any unrecognized symbols it couldn't set due to typos.)

--- Real-world example.

Here's the mini.config I use to build User Mode Linux:

CONFIG_MODE_SKAS=y
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_SYSCTL=y
CONFIG_STDERR_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_UBD=y
CONFIG_TMPFS=y
CONFIG_SWAP=y
CONFIG_LBD=y
CONFIG_EXT2_FS=y
CONFIG_PROC_FS=y

And here's how I build and test it (as a normal user, not as root):

# Configure, building in an external directory and using a mini.config file in
# my home directory.

make KCONFIG_ALLCONFIG=~/mini.config ARCH=um O=../linux-umlbuild allnoconfig

# change to build directory and build User Mode Linux

cd ../linux-umlbuild
make ARCH=um

# Test run

./linux rootfstype=hostfs rw init=/bin/sh
$ whoami
$ mount -t proc /proc /proc
$ cat /proc/cpuinfo
$ exit

--- Suggestions.

1) Add a "make miniconfig" which works like allnoconfig but A) takes 
mini.config as its' default name, B) redirects stdout to /dev/null to make it 
easier to spot typoed symbols, C) aborts (exits with an error, does not write 
new .config) if mini.config isn't found or if it contains an unrecognized 
symbol.

2) Fix the interaction with O= so that it looks for the mini.config file in 
the O= directory and not the source directory, so people don't _have_ to 
specify KCONFIG_ALLCONFIG when building out of tree.

Re: Quick and dirty miniconfig howto, with feature suggestions.

[Roman Zippel]

Hi,

On Thu, 17 Nov 2005, Rob Landley wrote:

> 1) Add a "make miniconfig" which works like allnoconfig but A) takes 
> mini.config as its' default name, B) redirects stdout to /dev/null to make it 
> easier to spot typoed symbols, C) aborts (exits with an error, does not write 
> new .config) if mini.config isn't found or if it contains an unrecognized 
> symbol.

I think I better make allnoconfig silent (unless with V=1 or something), 
which makes it your miniconfig already almost like allnoconfig.
I'm not quite sure about aborting there are other error possibilities 
(e.g. new dependencies), so you never quite can trust the error value 
anyway.

> 2) Fix the interaction with O= so that it looks for the mini.config file in 
> the O= directory and not the source directory, so people don't _have_ to 
> specify KCONFIG_ALLCONFIG when building out of tree.

I indeed need to fix this.

bye, Roman

Re: Quick and dirty miniconfig howto, with feature suggestions.

[Rob Landley]

On Saturday 19 November 2005 21:08, Roman Zippel wrote:
> Hi,
>
> On Thu, 17 Nov 2005, Rob Landley wrote:
> > 1) Add a "make miniconfig" which works like allnoconfig but A) takes
> > mini.config as its' default name, B) redirects stdout to /dev/null to
> > make it easier to spot typoed symbols, C) aborts (exits with an error,
> > does not write new .config) if mini.config isn't found or if it contains
> > an unrecognized symbol.
>
> I think I better make allnoconfig silent (unless with V=1 or something),
> which makes it your miniconfig already almost like allnoconfig.

That would be an improvement, but I think from a user interface perspective 
it's slightly confusing to overload allnoconfig.  (It's not a big issue 
either way, though.)

The output redirecton could actually be done trivially in the makefile without 
touching the config code, and the other changes I proposed are fairly small.    
I have a todo item to whip up a "make miniconfig" patch that adds a new 
target with all three of the small behavior changes.  I can submit that for 
consideration later this evening...

> I'm not quite sure about aborting there are other error possibilities
> (e.g. new dependencies), so you never quite can trust the error value
> anyway.

In theory, something based on allnoconfig shouldn't care about the previous 
state of the .config file, so how is a dependency "new"?  (Could you clarify 
what you mean?)

If the Kconfig tree has conflicting symbols in it (dependencies on something 
it can't find), then yeah it would exit with an error in that case.  But I'm 
not sure that's a down side, that's detecting a bug.

My use case is that I'm trying to run the build within a script, and if 
something goes wrong I want the build to abort then rather than have to 
backtrack later.  And when I'm testing it out from the command line, several 
times I've typoed "KCONFIG_ALLCONFIG=../path/to/miniconfig", and right now it 
happily does an allnoconfig that I have to examine to see if it's correct.  
For allnoconfig, there not being an allno.conf file is fine, but for 
miniconfig the action would be meaningless if the mini.conf isn't found, so 
it should error.

My take, anyway.  I'll come up with a patch...

Rob

[PATCH] make miniconfig

[Rob Landley]

Signed-off-by: Rob Landley <rob@landley.net>

Add "make miniconfig", plus documentation, plus the script that creates a
minimal mini.config from a normal .config file.
---
This patch is basically a user interface tweak to the new allno.config feature
that went into 2.6.15-rc1.  The differences between allnoconfig and miniconfig
are:

1) Documentation.

2) More easily understandable names (miniconfig and mini.config).

3) More user-friendly output (just show the warnings, not the successes).

4) Better error handling (the make exits with an error if mini.config isn't
found or if parsing mini.config generates any warnings).

5) A shell script to automatically create mini.config from a normal .config
file.  (It's very slow, but it works.  Anybody who wants to make confdata.c
spit this out by itself, feel free.  I definitely took the "bang two rocks
together, make fire" approach with this shell script.)

diff -ru linux-2.6.14/Documentation/miniconfig.txt 
linux-2.6.15-rc1/Documentation/miniconfig.txt
--- linux-2.6.14/Documentation/miniconfig.txt 2005-11-20 22:33:14.000000000 
-0600
+++ linux-2.6.15-rc1/Documentation/miniconfig.txt 2005-11-20 
23:30:13.000000000 -0600
@@ -0,0 +1,99 @@
+Miniconfig documentation
+November 21, 2005
+Rob Landley <rob@landley.net>
+=============================
+
+What is a miniconfig?
+---------------------
+
+A new feature introduced in 2.6.15 lets you use miniature configuration 
files,
+listing just the symbols you want to enable and letting the configurator
+enable any dependencies needed to give you a valid configuration.
+
+To use it, create a mini.config file in whatever directory your .config file
+would normally live in, and run "make miniconfig".  (You can specify a
+different file with the argument "KCONFIG_ALLCONFIG=/path/to/mini.config".)
+
+Advantages of miniconfig:
+-------------------------
+
+Miniconfigs have several advantages over conventional configuration files:
+
+ * They're more portable between versions.  A miniconfig from linux 2.6.15 
will
+   probably build an equivalent 2.6.16 kernel.
+
+ * It's easy to see exactly what features have been specified.
+
+ * Miniconfigs are human editable, human readable, and provide informative
+   error messages identifying any unrecognized (typoed) symbols.
+
+Creating a mini.config by hand:
+-------------------------------
+
+Run "make allnoconfig", and create an empty mini.config file.  Then go 
through
+"make menuconfig" enabling the features you want.  For each feature you 
enable,
+look at the help entry (at the top of which is the symbol name for this
+feature), and add a line to mini.config setting that symbol to the 
appropriate
+value, such as:
+
+CONFIG_THINGY=y
+
+Creating a mini.config from a full .config file:
+------------------------------------------------
+
+Run scripts/miniconfig.sh to automatically create a mini.conf from a full
+.config file.
+
+The script works via the simple expedient of trying to remove each line from
+.config and keeping only the lines which make a difference in the .config
+generated by "make miniconfig".  (This means it runs "make miniconfig" about
+1300 times, which is very very slow, so it displays a progress indicator.)
+
+To use the script, go into the kernel source directory, create your .config 
+file (via menuconfig or however), rename that .config file to another name
+(like "myconfig"), then run:
+
+scripts/miniconfig.sh myconfig
+
+When the script finishes, you should have a mini.config file containing
+the minimal set of lines necessary to specify that configuration via
+"make miniconfig".
+
+Real-world example:
+-------------------
+
+Here's the mini.config I use to build User Mode Linux:
+
+CONFIG_MODE_SKAS=y
+CONFIG_BINFMT_ELF=y
+CONFIG_HOSTFS=y
+CONFIG_SYSCTL=y
+CONFIG_STDERR_CONSOLE=y
+CONFIG_UNIX98_PTYS=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_UBD=y
+CONFIG_TMPFS=y
+CONFIG_SWAP=y
+CONFIG_LBD=y
+CONFIG_EXT2_FS=y
+CONFIG_PROC_FS=y
+
+And here's how I build and test it (as a normal user, not as root):
+
+# Configure, building in an external directory and using a mini.config file 
in
+# my home directory.
+
+make KCONFIG_ALLCONFIG=~/uml-config ARCH=um O=../linux-umlbuild miniconfig
+
+# change to build directory and build User Mode Linux
+
+cd ../linux-umlbuild
+make ARCH=um
+
+# Test run
+
+./linux rootfstype=hostfs rw init=/bin/sh
+$ whoami
+$ mount -t proc /proc /proc
+$ cat /proc/cpuinfo
+$ halt -f
diff -ru linux-2.6.14/scripts/kconfig/conf.c 
linux-2.6.15-rc1/scripts/kconfig/conf.c
--- linux-2.6.14/scripts/kconfig/conf.c 2005-11-20 04:27:22.000000000 -0600
+++ linux-2.6.15-rc1/scripts/kconfig/conf.c 2005-11-20 04:24:30.000000000 
-0600
@@ -24,7 +24,8 @@
  set_yes,
  set_mod,
  set_no,
- set_random
+ set_random,
+ set_mini
 } input_mode = ask_all;
 char *defconfig_file;
 
@@ -376,6 +377,7 @@
   case set_yes:
   case set_mod:
   case set_no:
+  case set_mini:
    cnt = def;
    printf("%d\n", cnt);
    break;
@@ -492,7 +494,7 @@
 
 int main(int ac, char **av)
 {
- int i = 1;
+ int i = 1, minifail = 0;
  const char *name;
  struct stat tmpstat;
 
@@ -530,6 +532,9 @@
    input_mode = set_random;
    srandom(time(NULL));
    break;
+  case 'M':
+   input_mode = set_mini;
+   break;
   case 'h':
   case '?':
    printf("%s [-o|-s] config\n", av[0]);
@@ -571,22 +576,32 @@
  case set_mod:
  case set_yes:
  case set_random:
+ case set_mini:
   name = getenv("KCONFIG_ALLCONFIG");
-  if (name && !stat(name, &tmpstat)) {
-   conf_read_simple(name);
-   break;
+  if (name) {
+   if(!stat(name, &tmpstat)) {
+    conf_read_simple(name);
+    break;
+   } else minifail++;
   }
   switch (input_mode) {
   case set_no:  name = "allno.config"; break;
   case set_mod:  name = "allmod.config"; break;
   case set_yes:  name = "allyes.config"; break;
   case set_random: name = "allrandom.config"; break;
+  case set_mini:  name = "mini.config"; break;
   default: break;
   }
   if (!stat(name, &tmpstat))
    conf_read_simple(name);
   else if (!stat("all.config", &tmpstat))
    conf_read_simple("all.config");
+  else minifail++;
+
+  if ( input_mode == set_mini && (minifail || conf_warnings)) {
+   fprintf(stderr, _("** Error parsing mini.config\n\n"));
+   return 1;
+  }
   break;
  default:
   break;
diff -ru linux-2.6.14/scripts/kconfig/confdata.c 
linux-2.6.15-rc1/scripts/kconfig/confdata.c
--- linux-2.6.14/scripts/kconfig/confdata.c 2005-11-20 04:27:22.000000000 
-0600
+++ linux-2.6.15-rc1/scripts/kconfig/confdata.c 2005-11-20 04:13:32.000000000 
-0600
@@ -18,7 +18,8 @@
  __attribute__ ((format (printf, 1, 2)));
 
 static const char *conf_filename;
-static int conf_lineno, conf_warnings, conf_unsaved;
+static int conf_lineno, conf_unsaved;
+int conf_warnings;
 
 const char conf_def_filename[] = ".config";
 
diff -ru linux-2.6.14/scripts/kconfig/lkc.h 
linux-2.6.15-rc1/scripts/kconfig/lkc.h
--- linux-2.6.14/scripts/kconfig/lkc.h 2005-11-20 04:27:22.000000000 -0600
+++ linux-2.6.15-rc1/scripts/kconfig/lkc.h 2005-11-20 04:14:53.000000000 -0600
@@ -61,6 +61,7 @@
 
 /* confdata.c */
 extern const char conf_def_filename[];
+extern int conf_warnings;
 
 char *conf_get_default_confname(void);
 
diff -ru linux-2.6.14/scripts/kconfig/Makefile 
linux-2.6.15-rc1/scripts/kconfig/Makefile
--- linux-2.6.14/scripts/kconfig/Makefile 2005-11-20 04:27:22.000000000 -0600
+++ linux-2.6.15-rc1/scripts/kconfig/Makefile 2005-11-20 23:43:57.000000000 
-0600
@@ -42,7 +42,7 @@
  $(Q)rm -f arch/um/Kconfig_arch
  $(Q)rm -f scripts/kconfig/linux_*.pot scripts/kconfig/config.pot
 
-.PHONY: randconfig allyesconfig allnoconfig allmodconfig defconfig
+.PHONY: randconfig allyesconfig allnoconfig allmodconfig defconfig miniconfig
 
 randconfig: $(obj)/conf
  $< -r arch/$(ARCH)/Kconfig
@@ -67,6 +67,9 @@
 %_defconfig: $(obj)/conf
  $(Q)$< -D arch/$(ARCH)/configs/$@ arch/$(ARCH)/Kconfig
 
+miniconfig: $(obj)/conf
+ @ $< -M arch/$(ARCH)/Kconfig > /dev/null
+
 # Help text used by make help
 help:
  @echo  '  config   - Update current config utilising a line-oriented 
program'
@@ -79,6 +82,7 @@
  @echo  '  allmodconfig   - New config selecting modules when possible'
  @echo  '  allyesconfig   - New config where all options are accepted with 
yes'
  @echo  '  allnoconfig   - New minimal config'
+ @echo  '  miniconfig   - New config generated from mini.config
 
 # ===========================================================================
 # Shared Makefile for the various kconfig executables:
diff -ru linux-2.6.14/scripts/miniconfig.sh 
linux-2.6.15-rc1/scripts/miniconfig.sh
--- linux-2.6.14/scripts/miniconfig.sh 2005-11-20 23:31:00.000000000 -0600
+++ linux-2.6.15-rc1/scripts/miniconfig.sh 2005-11-20 23:15:02.000000000 -0600
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+# miniconfig.sh copyright 2005 by Rob Landley <rob@landley.net>
+# Licensed under the GNU General Public License version 2.
+
+if [ $# -ne 1 ] || [ ! -f "$1" ]
+then
+  echo "Usage: miniconfig.sh configfile" 
+  exit 1
+fi
+
+if [ "$1" == ".config" ]
+then
+  echo "It overwrites .config, rename it and try again."
+  exit 1
+fi
+
+cp $1 mini.config
+echo "Calculating mini.config..."
+
+LENGTH=`cat $1 | wc -l`
+
+# Loop through all lines in the file 
+I=1
+while true
+do
+  if [ $I -gt $LENGTH ]
+  then
+    exit
+  fi
+  sed -n "${I}!p" mini.config > .config.test
+  # Do a config with this file
+  make allnoconfig KCONFIG_ALLCONFIG=.config.test > /dev/null
+
+  # Compare.  The date changes so expect a small difference each time.
+  D=`diff .config $1 | wc -l`
+  if [ $D -eq 4 ]
+  then
+    mv .config.test mini.config
+    LENGTH=$[$LENGTH-1]
+  else
+    I=$[$I + 1]
+  fi
+  echo -n -e $I/$LENGTH lines `cat mini.config | wc -c` bytes "\r"
+done
+echo

[PATCH] make miniconfig (take 2)

[Rob Landley]

Signed-off-by: Rob Landley <rob@landley.net>

Add "make miniconfig", plus documentation, plus the script that creates a
minimal mini.config from a normal .config file.
---
Blah.  Patch I sent last night was missing 2 lines in scripts/kconfig/conf.c
(in two case statements around lines 86 and 146 set_no: needed set_mini:
added).  Fixed and retested so that applying this patch gives the behavior I
tested, and while I was at it I tweaked the documentation a bit more.

Here's the extended description again:

This patch is basically a user interface tweak to the new allno.config
feature that went into 2.6.15-rc1.  The differences between allnoconfig and
miniconfig are:

1) Documentation.

2) More easily understandable names (miniconfig and mini.config).

3) More user-friendly output (just show the warnings, not the successes).

4) Better error handling (the make exits with an error if mini.config isn't
found or if parsing mini.config generates any warnings).

5) A shell script to automatically create mini.config from a normal .config
file.  (It's very slow, but it works.  Anybody who wants to make confdata.c
spit this out by itself, feel free.  I definitely took the "bang two rocks
together, make fire" approach with this shell script.)

diff -ru linux-2.6.15-rc2.old/Documentation/00-INDEX linux-2.6.15-rc2/Documentation/00-INDEX
--- linux-2.6.15-rc2.old/Documentation/00-INDEX 2005-11-21 09:28:04.000000000 -0600
+++ linux-2.6.15-rc2/Documentation/00-INDEX	2005-11-21 09:46:35.514090656 -0600
@@ -174,6 +174,8 @@
 	- info on boot arguments for the multiple devices driver.
 memory.txt
  - info on typical Linux memory problems.
+miniconfig.txt
+ - How to use miniature human-editable configuration files.
 mips/
  - directory with info about Linux on MIPS architecture.
 mono.txt
diff -ru linux-2.6.15-rc2.old/Documentation/miniconfig.txt linux-2.6.15-rc2/Documentation/miniconfig.txt
--- linux-2.6.15-rc2.old/Documentation/miniconfig.txt 2005-11-21 09:36:38.000000000 -0600
+++ linux-2.6.15-rc2/Documentation/miniconfig.txt 2005-11-21 09:45:23.561029184 -0600
@@ -0,0 +1,105 @@
+Miniconfig documentation
+November 21, 2005
+Rob Landley <rob@landley.net>
+=============================
+
+What is a miniconfig?
+---------------------
+
+A new feature introduced in 2.6.15 lets you use miniature configuration files,
+listing just the symbols you want to enable and letting the configurator
+enable any dependencies needed to give you a valid configuration.
+
+To use it, create a mini.config file in whatever directory your .config file
+would normally live in, and run "make miniconfig".  (You can specify a
+different file with the argument "KCONFIG_ALLCONFIG=/path/to/mini.config".)
+
+Advantages of miniconfig:
+-------------------------
+
+Miniconfigs have several advantages over conventional configuration files:
+
+ * They're more portable between versions.  A miniconfig from linux 2.6.15 will
+   probably build an equivalent 2.6.16 kernel.
+
+ * It's easy to see exactly what features have been specified.
+
+ * Miniconfigs are human editable, human readable, and provide informative
+   error messages identifying any unrecognized (typoed) symbols.
+
+Creating a mini.config by hand:
+-------------------------------
+
+Run "make allnoconfig", and create an empty mini.config file.  Then go through
+"make menuconfig" enabling the features you want.  For each feature you enable,
+look at the help entry (at the top of which is the symbol name for this
+feature), and add a line to mini.config setting that symbol to the appropriate
+value, such as:
+
+CONFIG_THINGY=y
+
+Creating a mini.config from a full .config file:
+------------------------------------------------
+
+Run scripts/miniconfig.sh to automatically create a mini.conf from a full
+.config file.
+
+The script works via the simple expedient of trying to remove each line from
+.config and keeping only the lines which make a difference in the .config
+generated by "make miniconfig".  (This means it runs "make miniconfig" about
+1300 times, which is very very slow, so it displays a progress indicator.)
+
+To use the script, go into the kernel source directory, create your .config 
+file (via menuconfig or however), rename that .config file to another name
+(like "myconfig"), then run:
+
+scripts/miniconfig.sh myconfig
+
+When the script finishes, you should have a mini.config file containing
+the minimal set of lines necessary to specify that configuration via
+"make miniconfig".
+
+Real-world example:
+-------------------
+
+Here's the mini.config I use to build User Mode Linux:
+
+CONFIG_MODE_SKAS=y
+CONFIG_BINFMT_ELF=y
+CONFIG_HOSTFS=y
+CONFIG_SYSCTL=y
+CONFIG_STDERR_CONSOLE=y
+CONFIG_UNIX98_PTYS=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_UBD=y
+CONFIG_TMPFS=y
+CONFIG_SWAP=y
+CONFIG_LBD=y
+CONFIG_EXT2_FS=y
+CONFIG_PROC_FS=y
+
+And here's how I build and test it (as a normal user, not as root):
+
+# Configure, building in an external directory and using a mini.config file in
+# my home directory.
+
+make KCONFIG_ALLCONFIG=~/uml-config ARCH=um O=../linux-umlbuild miniconfig
+
+# change to build directory and build User Mode Linux
+
+cd ../linux-umlbuild
+make ARCH=um
+
+# Test run
+
+./linux rootfstype=hostfs rw init=/bin/sh
+$ whoami
+$ mount -t proc /proc /proc
+$ cat /proc/cpuinfo
+$ halt -f
+
+# And if I want to regenerate the mini.config from the .config, I do this.
+# Note the syntax for specifying a different architecture:
+
+cp .config myconfig
+ARCH=um scripts/miniconfig.sh myconfig
diff -ru linux-2.6.15-rc2.old/scripts/kconfig/conf.c linux-2.6.15-rc2/scripts/kconfig/conf.c
--- linux-2.6.15-rc2.old/scripts/kconfig/conf.c 2005-11-21 09:28:22.000000000 -0600
+++ linux-2.6.15-rc2/scripts/kconfig/conf.c 2005-11-21 09:23:02.000000000 -0600
@@ -24,7 +24,8 @@
  set_yes,
  set_mod,
  set_no,
- set_random
+ set_random,
+ set_mini
 } input_mode = ask_all;
 char *defconfig_file;
 
@@ -86,6 +87,7 @@
  case set_mod:
  case set_yes:
  case set_random:
+ case set_mini:
   if (sym_has_value(sym)) {
    printf("%s\n", def);
    return;
@@ -143,6 +145,7 @@
    }
   }
  case set_no:
+ case set_mini:
   if (sym_tristate_within_range(sym, no)) {
    line[0] = 'n';
    line[1] = '\n';
@@ -376,6 +379,7 @@
   case set_yes:
   case set_mod:
   case set_no:
+  case set_mini:
    cnt = def;
    printf("%d\n", cnt);
    break;
@@ -492,7 +496,7 @@
 
 int main(int ac, char **av)
 {
- int i = 1;
+ int i = 1, minifail = 0;
  const char *name;
  struct stat tmpstat;
 
@@ -530,6 +534,9 @@
    input_mode = set_random;
    srandom(time(NULL));
    break;
+  case 'M':
+   input_mode = set_mini;
+   break;
   case 'h':
   case '?':
    printf("%s [-o|-s] config\n", av[0]);
@@ -571,22 +578,32 @@
  case set_mod:
  case set_yes:
  case set_random:
+ case set_mini:
   name = getenv("KCONFIG_ALLCONFIG");
-  if (name && !stat(name, &tmpstat)) {
-   conf_read_simple(name);
-   break;
+  if (name) {
+   if(!stat(name, &tmpstat)) {
+    conf_read_simple(name);
+    break;
+   } else minifail++;
   }
   switch (input_mode) {
   case set_no:  name = "allno.config"; break;
   case set_mod:  name = "allmod.config"; break;
   case set_yes:  name = "allyes.config"; break;
   case set_random: name = "allrandom.config"; break;
+  case set_mini:  name = "mini.config"; break;
   default: break;
   }
   if (!stat(name, &tmpstat))
    conf_read_simple(name);
   else if (!stat("all.config", &tmpstat))
    conf_read_simple("all.config");
+  else minifail++;
+
+  if ( input_mode == set_mini && (minifail || conf_warnings)) {
+   fprintf(stderr, _("** Error parsing mini.config\n\n"));
+   return 1;
+  }
   break;
  default:
   break;
diff -ru linux-2.6.15-rc2.old/scripts/kconfig/confdata.c linux-2.6.15-rc2/scripts/kconfig/confdata.c
--- linux-2.6.15-rc2.old/scripts/kconfig/confdata.c 2005-11-21 09:28:22.000000000 -0600
+++ linux-2.6.15-rc2/scripts/kconfig/confdata.c 2005-11-21 09:21:50.000000000 -0600
@@ -18,7 +18,8 @@
  __attribute__ ((format (printf, 1, 2)));
 
 static const char *conf_filename;
-static int conf_lineno, conf_warnings, conf_unsaved;
+static int conf_lineno, conf_unsaved;
+int conf_warnings;
 
 const char conf_def_filename[] = ".config";
 
diff -ru linux-2.6.15-rc2.old/scripts/kconfig/lkc.h linux-2.6.15-rc2/scripts/kconfig/lkc.h
--- linux-2.6.15-rc2.old/scripts/kconfig/lkc.h 2005-11-21 09:28:22.000000000 -0600
+++ linux-2.6.15-rc2/scripts/kconfig/lkc.h 2005-11-21 09:21:50.000000000 -0600
@@ -61,6 +61,7 @@
 
 /* confdata.c */
 extern const char conf_def_filename[];
+extern int conf_warnings;
 
 char *conf_get_default_confname(void);
 
diff -ru linux-2.6.15-rc2.old/scripts/kconfig/Makefile linux-2.6.15-rc2/scripts/kconfig/Makefile
--- linux-2.6.15-rc2.old/scripts/kconfig/Makefile 2005-11-21 09:28:22.000000000 -0600
+++ linux-2.6.15-rc2/scripts/kconfig/Makefile 2005-11-21 09:21:50.000000000 -0600
@@ -42,7 +42,7 @@
  $(Q)rm -f arch/um/Kconfig_arch
  $(Q)rm -f scripts/kconfig/linux_*.pot scripts/kconfig/config.pot
 
-.PHONY: randconfig allyesconfig allnoconfig allmodconfig defconfig
+.PHONY: randconfig allyesconfig allnoconfig allmodconfig defconfig miniconfig
 
 randconfig: $(obj)/conf
  $< -r arch/$(ARCH)/Kconfig
@@ -67,6 +67,9 @@
 %_defconfig: $(obj)/conf
  $(Q)$< -D arch/$(ARCH)/configs/$@ arch/$(ARCH)/Kconfig
 
+miniconfig: $(obj)/conf
+ @ $< -M arch/$(ARCH)/Kconfig > /dev/null
+
 # Help text used by make help
 help:
  @echo  '  config   - Update current config utilising a line-oriented program'
@@ -79,6 +82,7 @@
  @echo  '  allmodconfig   - New config selecting modules when possible'
  @echo  '  allyesconfig   - New config where all options are accepted with yes'
  @echo  '  allnoconfig   - New minimal config'
+ @echo  '  miniconfig   - New config generated from mini.config
 
 # ===========================================================================
 # Shared Makefile for the various kconfig executables:
diff -ru linux-2.6.15-rc2.old/scripts/miniconfig.sh linux-2.6.15-rc2/scripts/miniconfig.sh
--- linux-2.6.15-rc2.old/scripts/miniconfig.sh 2005-11-21 09:36:44.000000000 -0600
+++ linux-2.6.15-rc2/scripts/miniconfig.sh 2005-11-21 09:21:50.000000000 -0600
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+# miniconfig.sh copyright 2005 by Rob Landley <rob@landley.net>
+# Licensed under the GNU General Public License version 2.
+
+if [ $# -ne 1 ] || [ ! -f "$1" ]
+then
+  echo "Usage: miniconfig.sh configfile" 
+  exit 1
+fi
+
+if [ "$1" == ".config" ]
+then
+  echo "It overwrites .config, rename it and try again."
+  exit 1
+fi
+
+cp $1 mini.config
+echo "Calculating mini.config..."
+
+LENGTH=`cat $1 | wc -l`
+
+# Loop through all lines in the file 
+I=1
+while true
+do
+  if [ $I -gt $LENGTH ]
+  then
+    exit
+  fi
+  sed -n "${I}!p" mini.config > .config.test
+  # Do a config with this file
+  make allnoconfig KCONFIG_ALLCONFIG=.config.test > /dev/null
+
+  # Compare.  The date changes so expect a small difference each time.
+  D=`diff .config $1 | wc -l`
+  if [ $D -eq 4 ]
+  then
+    mv .config.test mini.config
+    LENGTH=$[$LENGTH-1]
+  else
+    I=$[$I + 1]
+  fi
+  echo -n -e $I/$LENGTH lines `cat mini.config | wc -c` bytes "\r"
+done
+echo

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

> diff -ru linux-2.6.15-rc2.old/scripts/miniconfig.sh linux-2.6.15-rc2/scripts/miniconfig.sh
> --- linux-2.6.15-rc2.old/scripts/miniconfig.sh 2005-11-21 09:36:44.000000000 -0600
> +++ linux-2.6.15-rc2/scripts/miniconfig.sh 2005-11-21 09:21:50.000000000 -0600
> @@ -0,0 +1,46 @@

I see the patch is now in mainline... unfortunately
scripts/miniconfig.sh does not seem to have execute permission.

							Pavel

-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Monday 21 November 2005 11:26, Pavel Machek wrote:
> Hi!
>
> > diff -ru linux-2.6.15-rc2.old/scripts/miniconfig.sh
> > linux-2.6.15-rc2/scripts/miniconfig.sh ---
> > linux-2.6.15-rc2.old/scripts/miniconfig.sh 2005-11-21 09:36:44.000000000
> > -0600 +++ linux-2.6.15-rc2/scripts/miniconfig.sh 2005-11-21
> > 09:21:50.000000000 -0600 @@ -0,0 +1,46 @@
>
> I see the patch is now in mainline... unfortunately
> scripts/miniconfig.sh does not seem to have execute permission.

Sorry.  I did a chmod +x here, but I dunno how to make diff -u care about 
permissions.  (I'm all ears.  Edit the -0600 by hand?)

Rob

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

> Signed-off-by: Rob Landley <rob@landley.net>
> 
> Add "make miniconfig", plus documentation, plus the script that creates a
> minimal mini.config from a normal .config file.
> ---
> Blah.  Patch I sent last night was missing 2 lines in scripts/kconfig/conf.c
> (in two case statements around lines 86 and 146 set_no: needed set_mini:
> added).  Fixed and retested so that applying this patch gives the behavior I
> tested, and while I was at it I tweaked the documentation a bit more.
> 
> Here's the extended description again:
> 
> This patch is basically a user interface tweak to the new allno.config
> feature that went into 2.6.15-rc1.  The differences between allnoconfig and
> miniconfig are:
> 
> 1) Documentation.
> 
> 2) More easily understandable names (miniconfig and mini.config).
> 
> 3) More user-friendly output (just show the warnings, not the successes).
> 
> 4) Better error handling (the make exits with an error if mini.config isn't
> found or if parsing mini.config generates any warnings).
> 
> 5) A shell script to automatically create mini.config from a normal .config
> file.  (It's very slow, but it works.  Anybody who wants to make confdata.c
> spit this out by itself, feel free.  I definitely took the "bang two rocks
> together, make fire" approach with this shell script.)

How is it supposed to work with cross-compiling.
								Pavel
-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Monday 21 November 2005 11:36, Pavel Machek wrote:
> How is it supposed to work with cross-compiling.

That's why I gave the User Mode Linux example in the documentation, which 
specifies an architecture.  (And in take 2, I added an example of running the 
makemini.sh script for UML, where you have to specify ARCH=um as an 
environment variable.)

If there's more to cross-compiling than that, please tell me and I'll work it 
in.  (I know you have to specify a cross toolchain, but I didn't think that 
affected the configure step...)

>         Pavel

Rob

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

> > How is it supposed to work with cross-compiling.
> 
> That's why I gave the User Mode Linux example in the documentation, which 
> specifies an architecture.  (And in take 2, I added an example of running the 
> makemini.sh script for UML, where you have to specify ARCH=um as an 
> environment variable.)
> 
> If there's more to cross-compiling than that, please tell me and I'll work it 
> in.  (I know you have to specify a cross toolchain, but I didn't think that 
> affected the configure step...)

I probably miss-patched my kernel, sorry. Not sure what you have to do
to change permissions, probably mail it to akpm and ask him to add +x
:-).
								Pavel
-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Monday 21 November 2005 12:28, Pavel Machek wrote:
> Hi!
>
> > > How is it supposed to work with cross-compiling.
> >
> > That's why I gave the User Mode Linux example in the documentation, which
> > specifies an architecture.  (And in take 2, I added an example of running
> > the makemini.sh script for UML, where you have to specify ARCH=um as an
> > environment variable.)
> >
> > If there's more to cross-compiling than that, please tell me and I'll
> > work it in.  (I know you have to specify a cross toolchain, but I didn't
> > think that affected the configure step...)
>
> I probably miss-patched my kernel, sorry. Not sure what you have to do
> to change permissions, probably mail it to akpm and ask him to add +x
>
> :-).

I'm hoping to get an ack from the kconfig guys first, hence the cc:

But does it work ok for you?

Rob

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

> > > > How is it supposed to work with cross-compiling.
> > >
> > > That's why I gave the User Mode Linux example in the documentation, which
> > > specifies an architecture.  (And in take 2, I added an example of running
> > > the makemini.sh script for UML, where you have to specify ARCH=um as an
> > > environment variable.)
> > >
> > > If there's more to cross-compiling than that, please tell me and I'll
> > > work it in.  (I know you have to specify a cross toolchain, but I didn't
> > > think that affected the configure step...)
> >
> > I probably miss-patched my kernel, sorry. Not sure what you have to do
> > to change permissions, probably mail it to akpm and ask him to add +x
> >
> > :-).
> 
> I'm hoping to get an ack from the kconfig guys first, hence the cc:
> 
> But does it work ok for you?

I was not even able to patch it properly :-(. Version against current
-git would be handy.
								Pavel
-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Monday 21 November 2005 13:24, Pavel Machek wrote:
> Hi!
> > I'm hoping to get an ack from the kconfig guys first, hence the cc:
> >
> > But does it work ok for you?
>
> I was not even able to patch it properly :-(. Version against current
> -git would be handy.

Ouch.  It applied cleanly against both -rc1 and -rc2.  Ok, um...

Is there any way to extract a current patch against 2.6.15-rc1-git1 from the 
git web page?  I can get the most _recent_ diff at: 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git

But that's just for one changeset.  Possibly I can iterate through the 
changesets to get all the diffs back to -git1 and apply them in sequence (if 
that works).  But the ability to right click and download one big rollup 
patch would be really really nice.

Rob

P.S.  I don't use git.  Poked at it a few times, but I made the mistake of 
reading largeish chunks of the git man page and the git glossary in an 
attempt to get up to speed, and got a headache.  Anything that can define 
"clean" in such a way that I'm _less_ sure of the definition afterwards:
http://www.kernel.org/pub/software/scm/git/docs/glossary.html
Learning git went back on the to-do list somewhere between cleaning behind the 
refrigerator and sorting my book collection by author...

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

> P.S.  I don't use git.  Poked at it a few times, but I made the mistake of 
> reading largeish chunks of the git man page and the git glossary in an 
> attempt to get up to speed, and got a headache.  Anything that can define 
> "clean" in such a way that I'm _less_ sure of the definition afterwards:
> http://www.kernel.org/pub/software/scm/git/docs/glossary.html
> Learning git went back on the to-do list somewhere between cleaning behind the 
> refrigerator and sorting my book collection by author...

Getting latest try via git is _really_ easy:


mkdir clean-cg; cd clean-cg
cg-init
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

... Do cg-update origin to pickup latest changes from Linus. You can
do cg-diff to see what changes you done in your local tree. cg-cancel
will kill any such changes, and cg-commit will make them permanent.

Sorry, I did not have time to look what's wrong with miniconfig, yet.

								Pavel

-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

On Tuesday 22 November 2005 16:54, Pavel Machek wrote:
> Sorry, I did not have time to look what's wrong with miniconfig, yet.

I just tried again and it applied to -git2 cleanly.  Possibly it was 
whitespace damaged?  (I have to jump through hoops to prevent kmail from 
doing stupid things to inline attachments...)

Here it is as an attachment.  Let me know if this applies cleanly for you...

Rob

[-- Attachment #2: miniconfig2.patch --]
[-- Type: text/x-diff, Size: 10203 bytes --]

diff -ru linux-2.6.15-rc2.old/Documentation/00-INDEX linux-2.6.15-rc2/Documentation/00-INDEX
--- linux-2.6.15-rc2.old/Documentation/00-INDEX	2005-11-21 09:28:04.000000000 -0600
+++ linux-2.6.15-rc2/Documentation/00-INDEX	2005-11-21 09:46:35.514090656 -0600
@@ -174,6 +174,8 @@
 	- info on boot arguments for the multiple devices driver.
 memory.txt
 	- info on typical Linux memory problems.
+miniconfig.txt
+	- How to use miniature human-editable configuration files.
 mips/
 	- directory with info about Linux on MIPS architecture.
 mono.txt
diff -ru linux-2.6.15-rc2.old/Documentation/miniconfig.txt linux-2.6.15-rc2/Documentation/miniconfig.txt
--- linux-2.6.15-rc2.old/Documentation/miniconfig.txt	2005-11-21 09:36:38.000000000 -0600
+++ linux-2.6.15-rc2/Documentation/miniconfig.txt	2005-11-21 09:45:23.561029184 -0600
@@ -0,0 +1,105 @@
+Miniconfig documentation
+November 21, 2005
+Rob Landley <rob@landley.net>
+=============================
+
+What is a miniconfig?
+---------------------
+
+A new feature introduced in 2.6.15 lets you use miniature configuration files,
+listing just the symbols you want to enable and letting the configurator
+enable any dependencies needed to give you a valid configuration.
+
+To use it, create a mini.config file in whatever directory your .config file
+would normally live in, and run "make miniconfig".  (You can specify a
+different file with the argument "KCONFIG_ALLCONFIG=/path/to/mini.config".)
+
+Advantages of miniconfig:
+-------------------------
+
+Miniconfigs have several advantages over conventional configuration files:
+
+ * They're more portable between versions.  A miniconfig from linux 2.6.15 will
+   probably build an equivalent 2.6.16 kernel.
+
+ * It's easy to see exactly what features have been specified.
+
+ * Miniconfigs are human editable, human readable, and provide informative
+   error messages identifying any unrecognized (typoed) symbols.
+
+Creating a mini.config by hand:
+-------------------------------
+
+Run "make allnoconfig", and create an empty mini.config file.  Then go through
+"make menuconfig" enabling the features you want.  For each feature you enable,
+look at the help entry (at the top of which is the symbol name for this
+feature), and add a line to mini.config setting that symbol to the appropriate
+value, such as:
+
+CONFIG_THINGY=y
+
+Creating a mini.config from a full .config file:
+------------------------------------------------
+
+Run scripts/miniconfig.sh to automatically create a mini.conf from a full
+.config file.
+
+The script works via the simple expedient of trying to remove each line from
+.config and keeping only the lines which make a difference in the .config
+generated by "make miniconfig".  (This means it runs "make miniconfig" about
+1300 times, which is very very slow, so it displays a progress indicator.)
+
+To use the script, go into the kernel source directory, create your .config 
+file (via menuconfig or however), rename that .config file to another name
+(like "myconfig"), then run:
+
+scripts/miniconfig.sh myconfig
+
+When the script finishes, you should have a mini.config file containing
+the minimal set of lines necessary to specify that configuration via
+"make miniconfig".
+
+Real-world example:
+-------------------
+
+Here's the mini.config I use to build User Mode Linux:
+
+CONFIG_MODE_SKAS=y
+CONFIG_BINFMT_ELF=y
+CONFIG_HOSTFS=y
+CONFIG_SYSCTL=y
+CONFIG_STDERR_CONSOLE=y
+CONFIG_UNIX98_PTYS=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_UBD=y
+CONFIG_TMPFS=y
+CONFIG_SWAP=y
+CONFIG_LBD=y
+CONFIG_EXT2_FS=y
+CONFIG_PROC_FS=y
+
+And here's how I build and test it (as a normal user, not as root):
+
+# Configure, building in an external directory and using a mini.config file in
+# my home directory.
+
+make KCONFIG_ALLCONFIG=~/uml-config ARCH=um O=../linux-umlbuild miniconfig
+
+# change to build directory and build User Mode Linux
+
+cd ../linux-umlbuild
+make ARCH=um
+
+# Test run
+
+./linux rootfstype=hostfs rw init=/bin/sh
+$ whoami
+$ mount -t proc /proc /proc
+$ cat /proc/cpuinfo
+$ halt -f
+
+# And if I want to regenerate the mini.config from the .config, I do this.
+# Note the syntax for specifying a different architecture:
+
+cp .config myconfig
+ARCH=um scripts/miniconfig.sh myconfig
diff -ru linux-2.6.15-rc2.old/scripts/kconfig/conf.c linux-2.6.15-rc2/scripts/kconfig/conf.c
--- linux-2.6.15-rc2.old/scripts/kconfig/conf.c	2005-11-21 09:28:22.000000000 -0600
+++ linux-2.6.15-rc2/scripts/kconfig/conf.c	2005-11-21 09:23:02.000000000 -0600
@@ -24,7 +24,8 @@
 	set_yes,
 	set_mod,
 	set_no,
-	set_random
+	set_random,
+	set_mini
 } input_mode = ask_all;
 char *defconfig_file;
 
@@ -86,6 +87,7 @@
 	case set_mod:
 	case set_yes:
 	case set_random:
+	case set_mini:
 		if (sym_has_value(sym)) {
 			printf("%s\n", def);
 			return;
@@ -143,6 +145,7 @@
 			}
 		}
 	case set_no:
+	case set_mini:
 		if (sym_tristate_within_range(sym, no)) {
 			line[0] = 'n';
 			line[1] = '\n';
@@ -376,6 +379,7 @@
 		case set_yes:
 		case set_mod:
 		case set_no:
+		case set_mini:
 			cnt = def;
 			printf("%d\n", cnt);
 			break;
@@ -492,7 +496,7 @@
 
 int main(int ac, char **av)
 {
-	int i = 1;
+	int i = 1, minifail = 0;
 	const char *name;
 	struct stat tmpstat;
 
@@ -530,6 +534,9 @@
 			input_mode = set_random;
 			srandom(time(NULL));
 			break;
+		case 'M':
+			input_mode = set_mini;
+			break;
 		case 'h':
 		case '?':
 			printf("%s [-o|-s] config\n", av[0]);
@@ -571,22 +578,32 @@
 	case set_mod:
 	case set_yes:
 	case set_random:
+	case set_mini:
 		name = getenv("KCONFIG_ALLCONFIG");
-		if (name && !stat(name, &tmpstat)) {
-			conf_read_simple(name);
-			break;
+		if (name) {
+			if(!stat(name, &tmpstat)) {
+				conf_read_simple(name);
+				break;
+			} else minifail++;
 		}
 		switch (input_mode) {
 		case set_no:	 name = "allno.config"; break;
 		case set_mod:	 name = "allmod.config"; break;
 		case set_yes:	 name = "allyes.config"; break;
 		case set_random: name = "allrandom.config"; break;
+		case set_mini:	 name = "mini.config"; break;
 		default: break;
 		}
 		if (!stat(name, &tmpstat))
 			conf_read_simple(name);
 		else if (!stat("all.config", &tmpstat))
 			conf_read_simple("all.config");
+		else minifail++;
+
+		if ( input_mode == set_mini && (minifail || conf_warnings)) {
+			fprintf(stderr, _("** Error parsing mini.config\n\n"));
+			return 1;
+		}
 		break;
 	default:
 		break;
diff -ru linux-2.6.15-rc2.old/scripts/kconfig/confdata.c linux-2.6.15-rc2/scripts/kconfig/confdata.c
--- linux-2.6.15-rc2.old/scripts/kconfig/confdata.c	2005-11-21 09:28:22.000000000 -0600
+++ linux-2.6.15-rc2/scripts/kconfig/confdata.c	2005-11-21 09:21:50.000000000 -0600
@@ -18,7 +18,8 @@
 	__attribute__ ((format (printf, 1, 2)));
 
 static const char *conf_filename;
-static int conf_lineno, conf_warnings, conf_unsaved;
+static int conf_lineno, conf_unsaved;
+int conf_warnings;
 
 const char conf_def_filename[] = ".config";
 
diff -ru linux-2.6.15-rc2.old/scripts/kconfig/lkc.h linux-2.6.15-rc2/scripts/kconfig/lkc.h
--- linux-2.6.15-rc2.old/scripts/kconfig/lkc.h	2005-11-21 09:28:22.000000000 -0600
+++ linux-2.6.15-rc2/scripts/kconfig/lkc.h	2005-11-21 09:21:50.000000000 -0600
@@ -61,6 +61,7 @@
 
 /* confdata.c */
 extern const char conf_def_filename[];
+extern int conf_warnings;
 
 char *conf_get_default_confname(void);
 
diff -ru linux-2.6.15-rc2.old/scripts/kconfig/Makefile linux-2.6.15-rc2/scripts/kconfig/Makefile
--- linux-2.6.15-rc2.old/scripts/kconfig/Makefile	2005-11-21 09:28:22.000000000 -0600
+++ linux-2.6.15-rc2/scripts/kconfig/Makefile	2005-11-21 09:21:50.000000000 -0600
@@ -42,7 +42,7 @@
 	$(Q)rm -f arch/um/Kconfig_arch
 	$(Q)rm -f scripts/kconfig/linux_*.pot scripts/kconfig/config.pot
 
-.PHONY: randconfig allyesconfig allnoconfig allmodconfig defconfig
+.PHONY: randconfig allyesconfig allnoconfig allmodconfig defconfig miniconfig
 
 randconfig: $(obj)/conf
 	$< -r arch/$(ARCH)/Kconfig
@@ -67,6 +67,9 @@
 %_defconfig: $(obj)/conf
 	$(Q)$< -D arch/$(ARCH)/configs/$@ arch/$(ARCH)/Kconfig
 
+miniconfig: $(obj)/conf
+	@ $< -M arch/$(ARCH)/Kconfig > /dev/null
+
 # Help text used by make help
 help:
 	@echo  '  config	  - Update current config utilising a line-oriented program'
@@ -79,6 +82,7 @@
 	@echo  '  allmodconfig	  - New config selecting modules when possible'
 	@echo  '  allyesconfig	  - New config where all options are accepted with yes'
 	@echo  '  allnoconfig	  - New minimal config'
+	@echo  '  miniconfig	  - New config generated from mini.config
 
 # ===========================================================================
 # Shared Makefile for the various kconfig executables:
diff -ru linux-2.6.15-rc2.old/scripts/miniconfig.sh linux-2.6.15-rc2/scripts/miniconfig.sh
--- linux-2.6.15-rc2.old/scripts/miniconfig.sh	2005-11-21 09:36:44.000000000 -0600
+++ linux-2.6.15-rc2/scripts/miniconfig.sh	2005-11-21 09:21:50.000000000 -0600
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+# miniconfig.sh copyright 2005 by Rob Landley <rob@landley.net>
+# Licensed under the GNU General Public License version 2.
+
+if [ $# -ne 1 ] || [ ! -f "$1" ]
+then
+  echo "Usage: miniconfig.sh configfile" 
+  exit 1
+fi
+
+if [ "$1" == ".config" ]
+then
+  echo "It overwrites .config, rename it and try again."
+  exit 1
+fi
+
+cp $1 mini.config
+echo "Calculating mini.config..."
+
+LENGTH=`cat $1 | wc -l`
+
+# Loop through all lines in the file 
+I=1
+while true
+do
+  if [ $I -gt $LENGTH ]
+  then
+    exit
+  fi
+  sed -n "${I}!p" mini.config > .config.test
+  # Do a config with this file
+  make allnoconfig KCONFIG_ALLCONFIG=.config.test > /dev/null
+
+  # Compare.  The date changes so expect a small difference each time.
+  D=`diff .config $1 | wc -l`
+  if [ $D -eq 4 ]
+  then
+    mv .config.test mini.config
+    LENGTH=$[$LENGTH-1]
+  else
+    I=$[$I + 1]
+  fi
+  echo -n -e $I/$LENGTH lines `cat mini.config | wc -c` bytes "\r"
+done
+echo

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

> > Sorry, I did not have time to look what's wrong with miniconfig, yet.
> 
> I just tried again and it applied to -git2 cleanly.  Possibly it was 
> whitespace damaged?  (I have to jump through hoops to prevent kmail from 
> doing stupid things to inline attachments...)
> 
> Here it is as an attachment.  Let me know if this applies cleanly
> for you...

Ok, this one applied okay for me. It still does not seem to work:

pavel@amd:/data/l/linux$ scripts/miniconfig.sh config.ok
Calculating mini.config...
pavel@amd:/data/l/linux$ cat mini.config
CONFIG_PM=y
pavel@amd:/data/l/linux$ 

...and yes, my config is definitely more complex than that, I
handselected only relevant PCI cards, for example.
							Pavel

-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Wednesday 23 November 2005 07:21, Pavel Machek wrote:
> Hi!
>
> > > Sorry, I did not have time to look what's wrong with miniconfig, yet.
> >
> > I just tried again and it applied to -git2 cleanly.  Possibly it was
> > whitespace damaged?  (I have to jump through hoops to prevent kmail from
> > doing stupid things to inline attachments...)
> >
> > Here it is as an attachment.  Let me know if this applies cleanly
> > for you...
>
> Ok, this one applied okay for me. It still does not seem to work:
>
> pavel@amd:/data/l/linux$ scripts/miniconfig.sh config.ok
> Calculating mini.config...
> pavel@amd:/data/l/linux$ cat mini.config
> CONFIG_PM=y
> pavel@amd:/data/l/linux$
>
> ...and yes, my config is definitely more complex than that, I
> handselected only relevant PCI cards, for example.
>        Pavel

Odd.

The way the script works is it repeatedly calls "make miniconfig" to see if 
removing each line makes a difference.  Judging by the output, it thinks none 
of the lines it removed made any difference.

Could you send me the .config you tried to shrink down?

Rob

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

> > > > Sorry, I did not have time to look what's wrong with miniconfig, yet.
> > >
> > > I just tried again and it applied to -git2 cleanly.  Possibly it was
> > > whitespace damaged?  (I have to jump through hoops to prevent kmail from
> > > doing stupid things to inline attachments...)
> > >
> > > Here it is as an attachment.  Let me know if this applies cleanly
> > > for you...
> >
> > Ok, this one applied okay for me. It still does not seem to work:
> >
> > pavel@amd:/data/l/linux$ scripts/miniconfig.sh config.ok
> > Calculating mini.config...
> > pavel@amd:/data/l/linux$ cat mini.config
> > CONFIG_PM=y
> > pavel@amd:/data/l/linux$
> >
> > ...and yes, my config is definitely more complex than that, I
> > handselected only relevant PCI cards, for example.
> >        Pavel
> 
> Odd.
> 
> The way the script works is it repeatedly calls "make miniconfig" to see if 
> removing each line makes a difference.  Judging by the output, it thinks none 
> of the lines it removed made any difference.
> 
> Could you send me the .config you tried to shrink down?

Here it is.

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.15-rc2
# Wed Nov 23 14:17:02 2005
#
CONFIG_X86_32=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y

#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_SYSCTL is not set
# CONFIG_HOTPLUG is not set
# CONFIG_IKCONFIG is not set
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Block layer
#
# CONFIG_LBD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
# CONFIG_HPET_TIMER is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PHYSICAL_START=0x100000

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set

#
# APM (Advanced Power Management) BIOS Support
#

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
# CONFIG_PCI is not set
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#

#
# Executable file formats
#
# CONFIG_BINFMT_ELF is not set
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Networking
#
# CONFIG_NET is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_FW_LOADER is not set

#
# Connector - unified userspace <-> kernelspace linker
#

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
# CONFIG_CDROM_PKTCDVD is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# I2O device support
#

#
# Network device support
#
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#

#
# I2C support
#
# CONFIG_I2C is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Misc devices
#

#
# Multimedia Capabilities Port drivers
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB_ARCH_HAS_HCD is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#

#
# SN Devices
#

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
# CONFIG_PROC_FS is not set
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_HFSPLUS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_EARLY_PRINTK=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC32 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y


-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Friday 25 November 2005 13:45, Pavel Machek wrote:
> > Odd.
> >
> > The way the script works is it repeatedly calls "make miniconfig" to see
> > if removing each line makes a difference.  Judging by the output, it
> > thinks none of the lines it removed made any difference.
> >
> > Could you send me the .config you tried to shrink down?
>
> Here it is.
>
> #
> # Automatically generated make config: don't edit
> # Linux kernel version: 2.6.15-rc2
> # Wed Nov 23 14:17:02 2005
...

Uh-huh.

  landley@driftwood:~/linux-2.6.15-rc2$ make allnoconfig > /dev/null
  landley@driftwood:~/linux-2.6.15-rc2$ diff -u .config pavelconfig
  --- .config     2005-11-25 15:38:49.333425064 -0600
  +++ pavelconfig3        2005-11-25 15:41:40.929338520 -0600
  @@ -1,7 +1,7 @@
   #
   # Automatically generated make config: don't edit
  -# Linux kernel version: 2.6.15-rc2-git2
  -# Fri Nov 25 15:38:49 2005
  +# Linux kernel version: 2.6.15-rc2
  +# Wed Nov 23 14:17:02 2005
   #
   CONFIG_X86_32=y
   CONFIG_SEMAPHORE_SLEEPERS=y
  landley@driftwood:~/linux-2.6.15-rc2$ 
  
Am I wrong, or is the .config you just sent me identical to the output of 
allnoconfig?  (I have no idea why it decided CONFIG_PM=y was needed, I just 
reproduced that here.  Probably an idiosyncrasy of allnoconfig, I could 
investigate that...)

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

> > #
> > # Automatically generated make config: don't edit
> > # Linux kernel version: 2.6.15-rc2
> > # Wed Nov 23 14:17:02 2005
> ...
> 
> Uh-huh.
> 
>   landley@driftwood:~/linux-2.6.15-rc2$ make allnoconfig > /dev/null
>   landley@driftwood:~/linux-2.6.15-rc2$ diff -u .config pavelconfig
>   --- .config     2005-11-25 15:38:49.333425064 -0600
>   +++ pavelconfig3        2005-11-25 15:41:40.929338520 -0600
>   @@ -1,7 +1,7 @@
>    #
>    # Automatically generated make config: don't edit
>   -# Linux kernel version: 2.6.15-rc2-git2
>   -# Fri Nov 25 15:38:49 2005
>   +# Linux kernel version: 2.6.15-rc2
>   +# Wed Nov 23 14:17:02 2005
>    #
>    CONFIG_X86_32=y
>    CONFIG_SEMAPHORE_SLEEPERS=y
>   landley@driftwood:~/linux-2.6.15-rc2$ 
>   
> Am I wrong, or is the .config you just sent me identical to the output of 
> allnoconfig?  (I have no idea why it decided CONFIG_PM=y was needed, I just 
> reproduced that here.  Probably an idiosyncrasy of allnoconfig, I could 
> investigate that...)

Ouch, I guess I killed my .config :-(. It seems that interrupted
miniconfig.sh leaves .config in close to empty state...

I'm not sure what I did wrong last time, it worked this time. My
miniconfig is 6K instead of 46K, good. Still its quite long. Thanks!

							Pavel
-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Friday 25 November 2005 16:09, Pavel Machek wrote:
> Ouch, I guess I killed my .config :-(. It seems that interrupted
> miniconfig.sh leaves .config in close to empty state...

That's why it insists you rename it in order to run it.

I intend to fix that somewhat in a newer version of the sucker by having the 
script intercept signals and restore .config on the way out, but it can't be 
fully reliable (not against kill -9) because kconfig overwrites .config and 
the script is repeatedly running allnoconfig.  (I can probably bypass the 
makefile and feed it some strange command line argument, but what Kconfig to 
run it on gets us into architecture dependence issues the make file handles 
for us...)

> I'm not sure what I did wrong last time, it worked this time. My
> miniconfig is 6K instead of 46K, good. Still its quite long. Thanks!

You mentioned you set a lot of options. :)

I agree scripts/miniconfig.sh is clumsy.  I'm thinking about improvements 
(both to how it works and to the user interface), but I need to catch up on 
some other stuff first...

>        Pavel

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [PATCH] make miniconfig (take 2)

[Kyle Moffett]

On Nov 25, 2005, at 17:20:12, Rob Landley wrote:

> On Friday 25 November 2005 16:09, Pavel Machek wrote:
>
>> Ouch, I guess I killed my .config :-(. It seems that interrupted
>> miniconfig.sh leaves .config in close to empty state...
>>
>
> That's why it insists you rename it in order to run it.
>
> I intend to fix that somewhat in a newer version of the sucker by  
> having the script intercept signals and restore .config on the way  
> out, but it can't be fully reliable (not against kill -9) because  
> kconfig overwrites .config and the script is repeatedly running  
> allnoconfig.  (I can probably bypass the makefile and feed it some  
> strange command line argument, but what Kconfig to run it on gets  
> us into architecture dependence issues the make file handles for  
> us...)
>

I got interested so I started writing a Perl-based replacement that  
actually reads the source config into program memory and writes  
copies out of that RAM each time.  I ran into a problem (although I  
can't reproduce it anymore) where the resultant configs had identical  
options but slightly altered whitespace or ordering, which naturally  
broke the diff method that miniconfig.sh used.


>> I'm not sure what I did wrong last time, it worked this time. My
>> miniconfig is 6K instead of 46K, good. Still its quite long. Thanks!
>>
>
> You mentioned you set a lot of options. :)
>
> I agree scripts/miniconfig.sh is clumsy.  I'm thinking about  
> improvements (both to how it works and to the user interface), but  
> I need to catch up on some other stuff first...
>

I have a bit of time to tinker.  I'll send you my perl version once I  
get it working and test it out a bit.  It shouldn't be too hard to  
add the ability to use .config and rewrite that when exiting.

One other minor nit:  If you pass a config file from a previous  
version to miniconfig.sh, it will return the full config file because  
nothing makes it match the original.  Theoretically it should  
probably allnoconfig with the full config first and use that for the  
rest, before removing lines.

Cheers,
Kyle Moffett

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Friday 25 November 2005 20:34, Kyle Moffett wrote:
> I got interested so I started writing a Perl-based replacement that
> actually reads the source config into program memory and writes
> copies out of that RAM each time.

I did several variants before settling on the one I submitted as "least sucky 
for right now".  (Starting from zero and adding lines did not work at _all_, 
and trying to produce consecutively smaller diffs isn't a winner either.  
Anything fancy based on diff runs into the fact that dependencies can enable 
stuff _earlier_ in the file, and it's almost impossible to parse.  Besides, 
diff is noticeably faster when there are few changes, so this was the best 
performer of the lot too...)

And I try to avoid perl dependencies in the linux build process.  When you do 
cross-compiles that make a minimal toolchain (ala the Linux From Scratch 
"/tools" directory) and then chroot into it to create the new system, having 
to add perl to the mess is a disproprotionate hassle.

> I ran into a problem (although I can't reproduce it anymore) where the
> resultant configs had identical options but slightly altered whitespace or
> ordering, which naturally broke the diff method that miniconfig.sh used.

Not a clue, sorry.  The date stamp changes, but that's expected white noise...

> >> I'm not sure what I did wrong last time, it worked this time. My
> >> miniconfig is 6K instead of 46K, good. Still its quite long. Thanks!
> >
> > You mentioned you set a lot of options. :)
> >
> > I agree scripts/miniconfig.sh is clumsy.  I'm thinking about
> > improvements (both to how it works and to the user interface), but
> > I need to catch up on some other stuff first...
>
> I have a bit of time to tinker.  I'll send you my perl version once I
> get it working and test it out a bit.  It shouldn't be too hard to
> add the ability to use .config and rewrite that when exiting.

I came back up to speed on Perl earlier this year (having last used perl 4 
before that), and reminded myself why I really can't stand it.  (scalar vs 
list context, local is an abuse of the exception handler, javadoc didn't have 
to modify the interpreter to ignore /** */ markup, pervasive use of call by 
reference means the exact same operator can act like a comparison or an 
assignment based on context ($x=~blah vs $x=~s/a/b/), references were nailed 
to the side of the language horribly, no language should force every program 
to start with a "suck less than the default" directive like use strict...  I 
could go on for a while...)  If I was going to bang on something more 
advanced than bash I could do a python version easily, but I don't want to 
assume that the target environment will have Python.

The dominant time factor is running allnoconfig.  (Last I checked anyway, 
there's been some development under the bridge since then, might be worth a 
re-profile.)  One speed improvement is that it should be possible to zap some 
of the comment lines without doing an actual allnoconfig.  (Certainly when 
there's a range of contiguous comment lines it could try zapping all of them 
and only iterating through one at a time if that makes a behavior difference, 
which it very seldom should.  That's a low-hanging fruit.)

Also, zappable lines tend to clump, so if it gets 2 zappable lines in a row it 
could speculatively try zapping 2 at a time to see if it makes faster 
progress.  (The down side is the extra allnoconfig runs for backing up and 
iterating through on failures to see _which_ ones made a difference.  That's 
not low-hanging fruit, may not be edible at all...)

> One other minor nit:  If you pass a config file from a previous
> version to miniconfig.sh, it will return the full config file because
> nothing makes it match the original.
>
> Theoretically it should 
> probably allnoconfig with the full config first and use that for the
> rest, before removing lines.

Yup.  That's an upgrade I already have planned.  Right now the mini.config 
files aren't version specific but the shrinker is, but that's easily fixable 
for 2.0.

I kept the shrinker script minimalistic because I was hoping that the kconfig 
guys might like the idea enough to make kconfig's existing infrastructure 
spit out a mini.config, rendering the script obsolete.  But now it's clear 
their reaction is intense distain, I might as well improve my hack since it 
looks like I'll be stuck with it for a while...

I'm pondering making a self-contained "./configure" wrapper script that 
obsoletes my patch (since they refuse to apply it anyway).  The question is 
should it rely on the new "allnoconfig" behavior, or should it just do 
everything with sed so it works with older Linux versions (and busybox and 
uclibc and so on)?  Haven't decided yet.

(Under ./configure, miniconfig.sh would probably become "./configure --export" 
or some such...)

> Cheers,
> Kyle Moffett

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

On So 26-11-05 06:25:30, Rob Landley wrote:
> On Friday 25 November 2005 20:34, Kyle Moffett wrote:
> > I got interested so I started writing a Perl-based replacement that
> > actually reads the source config into program memory and writes
> > copies out of that RAM each time.
> 
> I did several variants before settling on the one I submitted as "least sucky 
> for right now".  (Starting from zero and adding lines did not work at _all_, 
> and trying to produce consecutively smaller diffs isn't a winner either.  
> Anything fancy based on diff runs into the fact that dependencies can enable 
> stuff _earlier_ in the file, and it's almost impossible to parse.  Besides, 
> diff is noticeably faster when there are few changes, so this was the best 
> performer of the lot too...)
> 
> And I try to avoid perl dependencies in the linux build process.  When you do 
> cross-compiles that make a minimal toolchain (ala the Linux From Scratch 
> "/tools" directory) and then chroot into it to create the new system, having 
> to add perl to the mess is a disproprotionate hassle.

I'd say "don't worry about that, yet".

> Also, zappable lines tend to clump, so if it gets 2 zappable lines in a row it 
> could speculatively try zapping 2 at a time to see if it makes faster 
> progress.  (The down side is the extra allnoconfig runs for backing up and 
> iterating through on failures to see _which_ ones made a difference.  That's 
> not low-hanging fruit, may not be edible at all...)

Can't you just filter out all the comments beforehand?
								Pavel
-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Saturday 26 November 2005 08:19, Pavel Machek wrote:
> > Also, zappable lines tend to clump, so if it gets 2 zappable lines in a
> > row it could speculatively try zapping 2 at a time to see if it makes
> > faster progress.  (The down side is the extra allnoconfig runs for
> > backing up and iterating through on failures to see _which_ ones made a
> > difference.  That's not low-hanging fruit, may not be edible at all...)
>
> Can't you just filter out all the comments beforehand?

The problem is that the comments aren't all comments.  The
  # CONFIG_BLAH is not set
comments are actually like negative dentries specifying "CONFIG_BLAH=n", and 
otherwise it's unspecified which means you get the default.  (They look like 
comments, but they have meaning and yanking them can change behavior.)

This is noticeable if you feed a script through oldconfig, where everything 
that isn't specified one way or the other gets the default setting (which 
might as well be from randconfig).  But even allnoconfig has a lot of "y" 
entries in the resulting script, and some of them (like CONFIG_KALLSYMS or 
CONFIG_DEBUG_BUGVERBOSE) we may very well want to switch off.

Try this:

make allnoconfig
grep -v "^#" .config | grep -v "^$" > .config2
mv .config2 .config
make oldconfig

On the other hand, if you instead mv .config2 to allno.config and make 
allnoconfig, you get something that matches the original .config back.  And I 
haven't seen an "# blah is not set" line wind up in a miniconfig yet.

My understanding is that if you set the right symbol to open up the menu that 
a symbol you want to switch off is in, then not specifying a symbol in that 
menu leads allnoconfig to switch it off, since otherwise it would have to be 
specified.  It's only closed menus that get the defaults.  So if you 
originally created your .config through menuconfig, the "# is not set" lines 
should never be essential.  I think.  (By the way: note that the contents of 
a lot of submenus never actually get written out at all if their guard symbol 
is switched off.  Look at firewire or i2o support in 
allnoconfig's .config...)

(I spent a lot of time poking at this to make miniconfig work back under 
2.6.10.  And the busybox CONFIG_ vs ENABLE_ stuff, too...)

Then again I still haven't figured out why running the shrinker script against 
allnoconfig's config insists that CONFIG_PM=y still has to be set or the 
behavior changes.  Something I need to look at one of these days...

In any case, 99% of the time we should be able to ignore the comments and that 
lets us skip large chunks of config and should be a noticeable speedup.  A 
fallback to handle cases where the "is not set" comments change stuff may be 
sheer paranoia, but I can't be sure it's never necessary just yet...

>         Pavel

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Wednesday 23 November 2005 07:21, Pavel Machek wrote:
> Ok, this one applied okay for me. It still does not seem to work:
>
> pavel@amd:/data/l/linux$ scripts/miniconfig.sh config.ok
> Calculating mini.config...
> pavel@amd:/data/l/linux$ cat mini.config
> CONFIG_PM=y
> pavel@amd:/data/l/linux$
>
> ...and yes, my config is definitely more complex than that, I
> handselected only relevant PCI cards, for example.

This is a wild hunch, but try changing the #!/bin/sh at the top of 
miniconfig.sh to #!/bin/bash and see if that makes a difference?  (I vaguely 
remember an ancient email where you're using a funky shell?)

Rob

Re: [PATCH] make miniconfig (take 2)

[Pavel Machek]

Hi!

> > Ok, this one applied okay for me. It still does not seem to work:
> >
> > pavel@amd:/data/l/linux$ scripts/miniconfig.sh config.ok
> > Calculating mini.config...
> > pavel@amd:/data/l/linux$ cat mini.config
> > CONFIG_PM=y
> > pavel@amd:/data/l/linux$
> >
> > ...and yes, my config is definitely more complex than that, I
> > handselected only relevant PCI cards, for example.
> 
> This is a wild hunch, but try changing the #!/bin/sh at the top of 
> miniconfig.sh to #!/bin/bash and see if that makes a difference?  (I vaguely 
> remember an ancient email where you're using a funky shell?)

No, not it:

pavel@amd:~/sf/routeplanner$ ls -al /bin/sh
lrwxrwxrwx  1 root root 4 Nov 22 15:01 /bin/sh -> bash

Yes, I'm using some strange shell on zaurus system, but this is just
plain PC.
								Pavel
-- 
Thanks, Sharp!

Re: [PATCH] make miniconfig (take 2)

[Andre Noll]

Hi

On 20:46, Pavel Machek wrote:

> No, not it:
> 
> pavel@amd:~/sf/routeplanner$ ls -al /bin/sh
> lrwxrwxrwx  1 root root 4 Nov 22 15:01 /bin/sh -> bash

Even in that case '/bin/sh' and '/bin/bash' are not the same. From
the bash man page:

	If  bash  is invoked with the name sh, it tries to mimic
	the startup behavior of historical versions of sh as closely
	as possible...

Andre
-- 
Jesus not only saves, he also frequently makes backups

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Monday 21 November 2005 13:24, Pavel Machek wrote:
> Hi!
> > > I probably miss-patched my kernel, sorry. Not sure what you have to do
> > > to change permissions, probably mail it to akpm and ask him to add +x
> > >
> > > :-).
> >
> > I'm hoping to get an ack from the kconfig guys first, hence the cc:
> >
> > But does it work ok for you?
>
> I was not even able to patch it properly :-(. Version against current
> -git would be handy.

It still applied cleanly to 2.6.15-rc2-git1, which is the most recent version 
I currently know how to squeeze out of the web interface.  What tree are you 
attempting to apply it to?

Rob

Re: [PATCH] make miniconfig (take 2)

[Roman Zippel]

Hi,

On Mon, 21 Nov 2005, Rob Landley wrote:

> Add "make miniconfig", plus documentation, plus the script that creates a
> minimal mini.config from a normal .config file.

The difference between miniconfig and allnoconfig is IMO too small to be 
really worth it right now.

If we go that path, this functionality should be integrated properly.
What I have in mind is to create a new config file with a bit different 
format, which is only read by kconfig. This one can also have a switch 
"only save the minimum". The important part is that if this file exists, 
all kconfig front ends will use it and keep it properly uptodate.

'make miniconfig' would then simply convert the current config to a 
minimized version. One problem I see with this how kconfig should behave, 
when it's thrown into a new kernel release. Setting everything else to 'n' 
is one possibility, but sometimes such options as CONFIG_SWAP are added, 
which one certainly wants enabled. Using the defaults would be a 
possibility, but they are currently massively abused (and I'll probably 
soon start a cleanup of them).

> 1) Documentation.

This is of course always nice, but it would be even better, if it also 
included information about the other config targets, even it's mostly a 
place holder.

bye, Roman

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Thursday 24 November 2005 07:56, Roman Zippel wrote:
> Hi,
>
> On Mon, 21 Nov 2005, Rob Landley wrote:
> > Add "make miniconfig", plus documentation, plus the script that creates a
> > minimal mini.config from a normal .config file.
>
> The difference between miniconfig and allnoconfig is IMO too small to be
> really worth it right now.

I disagree, fairly strongly.  The technical difference may be small, but the 
conceptual difference is huge.

>From a user interface perspective, make miniconfig and make allnoconfig are 
two very different things.  Make allnoconfig is supposed to make a config 
where you answer "no" to all the questions.  The name is fairly intuitive.  
>From a user interface perspective, overloading it with miniconfig 
functionality kind of sucks.  When a user is supplying a miniconfig, what 
they're trying to accomplish is _different_ than what allnoconfig has 
traditionally done.  The fact that the same infrastructure can do both is an 
implementation detail.  Even if there were _no_ other changes, I'd urge 
adding it as a synonym that takes a different filename.

That's apart from the fact that allnoconfig doesn't return an error when you 
try to set nonexistent symbols (which makes sense for allnoconfig; any 
warnings there really aren't something a user is normally interested in).  Or 
that the pointless information it dumps to stdout buries any useful 
information going to stderr (again, for allnoconfig the warnings are only 
really of interest to developers).

Or the _big_ change, that miniconfig should _die_ if it can't find the 
mini.config file (because it has nothing to do), yet allnoconfig happily 
completes successfully.  That is the right thing for allnoconfig to do, and 
exactly the _wrong_ thing for miniconfig to do.  (It's especially problematic 
when specifying an alternate location for the file: if you typo it, there's 
no way to tell except by inspecting the verbose .config, or else finding out 
after you build that you built garbage.)

If your objection is to the size of the patch, I can make the patch bigger.  
Seems kind of counterproductive and something I was actually trying to 
_avoid_ doing.  (I didn't even rename KCONFIG_ALLSYMS, despite having to look 
the darn name up every single time I use it, because I was trying to keep the 
footprint down.)  But if the change isn't _big_ enough...

By the way, various other bits of the kernel build don't give me an error 
return when something goes wrong.  (For example, if a config 
CONFIG_INITRAMFS_SOURCE that doesn't exist, the build happily completes with 
an empty initramfs.  I have a to-do item to patch that, but it's a bit down 
on the list.  (Also, note that the fact you can specify things like 
CONFIG_INITRAMFS_SOURCE and CONFIG_LOG_BUF_SHIFT is obvious when talking 
about mini.config but an "aha" moment when talking about allno.config.  I 
like things that need fewer "aha" moments to understand.)

> If we go that path, this functionality should be integrated properly.

I've actually been using condensed configuration subsets since March 16 
(according to my build log http://www.landley.net/code/firmware/notes.html).  
I.E. I was already doing this eight months ago.  This functionality was 
already of use to me long before it came up on the list, and I think it would 
be something of larger utility if it were properly documented.

Which is why my first step was documenting the new way of doing things when 
2.6.15-rc1 broke something that had worked for me consistently ever since 
2.6.10.  (Of course I could have also documented how to work around the 
breakage by now sticking the symbols at the _start_ of the file.  But that 
wouldn't have been polite.)

The new "recommended" mechanism for doing what I wanted was not only entirely 
undocumented (and documenting it is where I noticed that the user interface 
sucked), but also the fact it was of use to me seemed largely accidental.  It 
was a side effect of a change that added variants like "allrandom.config".  
Keep in mind that I was moved to do this work because the way I'd _been_ 
performing this function for 8 months got broken by random outside 
developments.  So now it's a side effect of a _new_ set of things.  Wheee.

I'm all for future improvements.  My makemini.sh shell script sucks deeply, 
I'll be the first to acknowledge that.  But what I've proposed is a user 
interface I can document, one that meets my needs, and one I expect will be 
useful to others who are not deeply familiar with the configuration 
internals.

I could always treat the whole "make config" as something to be worked around 
with a wrapper script to give it a user interface based on the task humans 
are trying to do rather than how the plumbing happens to be laid out.  (The 
logical name for the new script would of course be "./configure".)  But I'd 
rather work _with_ the kernel than against it, and make it easier for others 
to do what I find useful.

I really do think this is an improvement from a user interface perspective, 
and the smallest change I could come up with from a technical perspective to 
meet my goals.

> What I have in mind is to create a new config file with a bit different
> format,

What's wrong with the format of mini.config?

> which is only read by kconfig.

So it would be different from the format of the busybox .config file, the 
uClibc .config file, or anybody else out there who's adopted the kernel's 
format over the past decade-plus?

> This one can also have a switch  
> "only save the minimum". The important part is that if this file exists,
> all kconfig front ends will use it and keep it properly uptodate.

I'd be quite happy if mini.config could be written directly by kconfig.  (It 
would do a much faster job than my dumb shrinker script.  I repeat: my 
shrinker script is crap.)

However, you seem to be forgetting that .config is read by the kernel build 
infrastructure.  The tools are generating what _used_ to be a human editable 
file. 

> 'make miniconfig' would then simply convert the current config to a
> minimized version.

So the new format would _not_ be a minimized version.  Uh-huh.  So there's 
still two versions...

So how would you make use of this new minimized version, then?  If somebody 
file attached one in a linux kernel message and a developer wanted to debug 
their issue?

> One problem I see with this how kconfig should behave, 
> when it's thrown into a new kernel release.

With mini.config, it's actually fairly portable between versions.  (As I said, 
it's worked for me since 2.6.10.)  It specifies the interesting symbols (the 
ones I'd specify in menuconfig), and then the dependencies should resolve 
themselves (which kconfig does right now).  New versions seldom drop or 
rename interesting features (if they did, make oldconfig wouldn't be of much 
use).  The simple fact is, mini.config doesn't specify anything particularly 
version specific.  The dependencies are in the stuff it _doesn't_ mention, it 
just says "I want this set of features" and any kernel newer than the one it 
was created on should have them unless they got obsoleted (which requires 
human intervention to fix anyway).

In fact, my old uml-config file from a few versions back still works in 2.6.15 
just fine.  It works as a mini.config, or it works if I append the .config 
generated by "make allnoconfig" file to _it_ rather than appending it to 
the .config, before running "make oldconfig" to clean it up.  That change was 
only required because some random code change the kconfig developers made 
broke it, because the behavior I was counting on was never intentional.

I'd like the behavior I'm relying on to be clearly intentional.  Not an 
accident that works until the next time the kconfig code is touched.

> Setting everything else to 'n' 
> is one possibility, but sometimes such options as CONFIG_SWAP are added,
> which one certainly wants enabled. Using the defaults would be a
> possibility, but they are currently massively abused (and I'll probably
> soon start a cleanup of them).

The miniconfigs I've been using (and the ones this patch uses) are based on 
allnoconfig.  This means that any features I don't specify, I probably don't 
want unless they're actually required.  That can be version independent.  
That's much less likely to introduce strange new things like devfs 
automounting 

> > 1) Documentation.
>
> This is of course always nice, but it would be even better, if it also
> included information about the other config targets, even it's mostly a
> place holder.

Why?  The target audience for miniconfig is people who want to save the work 
they did in menuconfig (and yes, configuring a kernel is work) without tons 
of extraneous version-dependent crap.  So they can give it to someone else 
who can see what options were important to them without having to pull up a 
GUI to interperet the data for them.  And so they can bring it forward to new 
versions.

And no, taking your 2.6.12 .config and running "make oldconfig" against it is 
_not_ a solution because any new symbols are set to the defaults out of 
defconfig, and a lot of those defaults are switched on.  So if you just run 
oldconfig (or make menuconfig and exit without dredging through each sub-menu 
looking for symbols marked "new", which isn't 100% reliable) you wind up with 
new extraneous crap accumulating in your config file with each version.

And no, you can't go `yes "n" | make oldconfig` because that goes into an 
endless loop when oldconfig prompts you for a number.  Been there, done 
that...

I don't personally _care_ about the other config targets.  They don't do what 
I'm trying to do here.  Conceptually, mini.config files are different 
from .config files because mini.config files are human editable and version 
independent.  Conventional .config files are neither.  I'm trying to document 
a useful technique which, to me, has _nothing_ to do with the rest of the 
plumbing changes you made.  It's a technique I was using long before the 
latest batch of changes, and your changes made it easier to promote it to a 
fully supported feature but it really doesn't seem to me that this technique 
was not what you had in mind when you made your changes.

I realise that you added allyes.config, allrandom.config, allmod.config, and 
so on.  But allnoconfig was the _only_ sane base for what I was trying to do.  
I did actually think this through, many moons ago.

defconfig changes from version to version.  New drivers show up for things you 
don't have.  Stuff you were using could go away simply because the defaults 
changed.  It's close to useless.

Allyesconfig and allmodconfig are not a sane base.  New drivers show up all 
the time so switching off everything you don't need is A) insanely verbose, 
B) not portable to new versions with new drivers.  And new stuff can show up 
that breaks you: devfs automounting, 

What's allrandom.config even for?  Maybe it's potentially a developer only 
thing to ensure that an allrandconfig kernel has the minimal set of options 
to potentially boot on your test hardware.  (Except that make allrandconfig 
is used almost exclusively to test _building_, not booting, because testing 
that hardware you don't have isn't found by the probes generally is not all 
that interesting of a test (and one you could pretty much do with 
allyesconfig or allmodconfig if you cared).  But maybe I could see the Linux 
Test Project guys potentially spending spare cycles on this.)  But again, 
completely different group of people than the audience for make miniconfig.

> bye, Roman

I have something working now, something a lot of thought went into.  I really 
do think it's a good idea...

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [PATCH] make miniconfig (take 2)

[Roman Zippel]

Hi,

On Thu, 24 Nov 2005, Rob Landley wrote:

> > On Mon, 21 Nov 2005, Rob Landley wrote:
> > > Add "make miniconfig", plus documentation, plus the script that creates a
> > > minimal mini.config from a normal .config file.
> >
> > The difference between miniconfig and allnoconfig is IMO too small to be
> > really worth it right now.
> 
> I disagree, fairly strongly.  The technical difference may be small, but the 
> conceptual difference is huge.

I don't really disagree, a proper implementation of the concept would also 
be technically quite different. Hacking it into conf.c is the wrong to go 
(or to even start).

> > which is only read by kconfig.
> 
> So it would be different from the format of the busybox .config file, the 
> uClibc .config file, or anybody else out there who's adopted the kernel's 
> format over the past decade-plus?

Did I say it would go away? No.
It actually makes quite some sense to separate the .config used by kbuild 
from the config used by kconfig.
.config isn't always correctly reread after a manual edit. The syntax 
rules needed by kbuild are more strict than needed for kconfig. The "is 
not set" syntax is not exactly user friendly and all the derived symbols 
aren't needed by kconfig.
My current plan is to somewhere create a copy of .config replacing 
the include/config/MARKER mechanism, which then is also used by kbuild.
In a second step it then would be simple to allow an alternative name 
or even formats for the primary config file.

> However, you seem to be forgetting that .config is read by the kernel build 
> infrastructure.  The tools are generating what _used_ to be a human editable 
> file. 

Oh, really?

> So how would you make use of this new minimized version, then?  If somebody 
> file attached one in a linux kernel message and a developer wanted to debug 
> their issue?

$ cp ... linux/config
$ make

> I don't personally _care_ about the other config targets.

Well, that's the problem, I do care about them. I want to keep it working 
without obfuscating it with thousands little features, so we have to 
figure out how to integrate it properly into the big picture.

bye, Roman

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Thursday 24 November 2005 19:48, Roman Zippel wrote:
> Hi,
>
> On Thu, 24 Nov 2005, Rob Landley wrote:
> > > On Mon, 21 Nov 2005, Rob Landley wrote:
> > > > Add "make miniconfig", plus documentation, plus the script that
> > > > creates a minimal mini.config from a normal .config file.
> > >
> > > The difference between miniconfig and allnoconfig is IMO too small to
> > > be really worth it right now.
> >
> > I disagree, fairly strongly.  The technical difference may be small, but
> > the conceptual difference is huge.
>
> I don't really disagree, a proper implementation of the concept would also
> be technically quite different.

But would the user interface?

> Hacking it into conf.c is the wrong to go (or to even start).

Hang on, you want a new user interface that does _not_ modify conf.c?

I can do that.  One ./configure wrapper script coming up...

> > So it would be different from the format of the busybox .config file, the
> > uClibc .config file, or anybody else out there who's adopted the kernel's
> > format over the past decade-plus?
>
> Did I say it would go away? No.
> It actually makes quite some sense to separate the .config used by kbuild
> from the config used by kconfig.
> .config isn't always correctly reread after a manual edit. The syntax
> rules needed by kbuild are more strict than needed for kconfig. The "is
> not set" syntax is not exactly user friendly and all the derived symbols
> aren't needed by kconfig.

Uh-huh.  So doing this requires a complete rewrite of kconfig.  And how long 
is this rewrite expected to take?  (Will it be in python and called CML2?)

Meanwhile, I have a small patch that provides this (from a user perspective) 
now.  Working today.  And I can also do a wrapper script so that Linux uses 
approximately the same ./configure; make; make install semantics as 95% of 
the other projects out there.

The fact that my patch works today is not an excuse for a complete rewrite of 
kconfig.  If you want to rewrite kconfig from scratch, fine.  But what I'm 
trying to do is not a reason for it.

> My current plan is to somewhere create a copy of .config replacing
> the include/config/MARKER mechanism, which then is also used by kbuild.

So you have to modify not just kconfig but kbuild also for your plan.  What 
are the advantages of doing this again?

> In a second step it then would be simple to allow an alternative name
> or even formats for the primary config file.

How far will they be allowed to diverge?  Will the use the same symbol names, 
or will there be some kind of translation table?

> > However, you seem to be forgetting that .config is read by the kernel
> > build infrastructure.  The tools are generating what _used_ to be a human
> > editable file.
>
> Oh, really?

This is a slightly vague.  Is this "Oh, really?" arguing that it didn't used 
to be a human readable format?

> > So how would you make use of this new minimized version, then?  If
> > somebody file attached one in a linux kernel message and a developer
> > wanted to debug their issue?
>
> $ cp ... linux/config
> $ make
>
> > I don't personally _care_ about the other config targets.
>
> Well, that's the problem, I do care about them.

I think you're too focused on the implementation to see the users.  What I'm 
trying to document is miniconfig, and as such any kallsyms target allnoconfig 
is not _useful_.

> I want to keep it working without obfuscating it with thousands little
> features, so we have to figure out how to integrate it properly into the big
> picture. 

Do you have a suggestion that does not involve a complete rewrite of kbuild 
over the next year or more?  I just posted one, and I've just started work on 
another.

I'm still not entirely certain you understand what I'm trying to accomplish, 
and I'm sorry I can't make you understand why I need this.  I'm not convinced 
that your "new config format" will be at all useful.

But oh well.  If you prefer I treat kbuild's user interface as something 
broken to be worked around with a wrapper script, I'm fine with that.  You're 
right, I don't really need to touch the implementation of kconfig.  Thanks 
for pointing that out.

> bye, Roman

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [PATCH] make miniconfig (take 2)

[Roman Zippel]

Hi,

On Fri, 25 Nov 2005, Rob Landley wrote:

> > I don't really disagree, a proper implementation of the concept would also
> > be technically quite different.
> 
> But would the user interface?

It would be a bit different from what you propose.

> Uh-huh.  So doing this requires a complete rewrite of kconfig.  And how long 
> is this rewrite expected to take?  (Will it be in python and called CML2?)

Rob, if you want me to just ignore you, then please continue like this.

> Meanwhile, I have a small patch that provides this (from a user perspective) 
> now.  Working today.

The point is that it's close enough to allnoconfig, so that it's IMO not 
worth it. I'm trying to explain, what would be needed to do it properly, 
but either I failed to make myself understandable or you're not listening.

> > > However, you seem to be forgetting that .config is read by the kernel
> > > build infrastructure.  The tools are generating what _used_ to be a human
> > > editable file.
> >
> > Oh, really?
> 
> This is a slightly vague.  Is this "Oh, really?" arguing that it didn't used 
> to be a human readable format?

At this point I was just wondering, whether you realize that I wrote the 
new kconfig stuff.

> > > I don't personally _care_ about the other config targets.
> >
> > Well, that's the problem, I do care about them.
> 
> I think you're too focused on the implementation to see the users.  What I'm 
> trying to document is miniconfig, and as such any kallsyms target allnoconfig 
> is not _useful_.

I'm actually quite interested in the needs of the users, but OTOH users 
have to realize that they are not always _exactly_ get what they want. 
Users often have very specific wishes and I try to provide a generic 
framework, which not only solves specific problems but also a broad range 
of problems, which often means to compromise as user needs can be very 
contradictory.

> > I want to keep it working without obfuscating it with thousands little
> > features, so we have to figure out how to integrate it properly into the big
> > picture. 
> 
> Do you have a suggestion that does not involve a complete rewrite of kbuild 
> over the next year or more?  I just posted one, and I've just started work on 
> another.
> 
> I'm still not entirely certain you understand what I'm trying to accomplish, 
> and I'm sorry I can't make you understand why I need this.  I'm not convinced 
> that your "new config format" will be at all useful.

I think I understand you quite well. Again, the basic functionality you 
want is already provided by allnoconfig and the advanced features need a 
bit more work than the few hacks you added to conf.c.
I like the idea of a minimum config, which e.g. users can send to 
developers or they can use for upgrading kernels, but this has to work not
just for you, but also for the majority of users and this requires a 
better specification of how this feature should work in various 
situations.

bye, Roman

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Friday 25 November 2005 09:02, Roman Zippel wrote:
> Hi,
>
> On Fri, 25 Nov 2005, Rob Landley wrote:
> > > I don't really disagree, a proper implementation of the concept would
> > > also be technically quite different.
> >
> > But would the user interface?
>
> It would be a bit different from what you propose.

You mean that what I've been happily using for eight months.

What would the different interface be, and what would the advantage be?  (Are 
you proposing a different file format?)

> > Uh-huh.  So doing this requires a complete rewrite of kconfig.  And how
> > long is this rewrite expected to take?  (Will it be in python and called
> > CML2?)
>
> Rob, if you want me to just ignore you, then please continue like this.

You've already made up your mind about the patch, based entirely on opinion 
rather than technical arguments.  I'm not convinced you've even read my list 
of reasons for the patch.  (You certainly haven't responded to any of the 
actual reasons, such as failure to find the config file being grounds for a 
build break with miniconfig but not for allnoconfig.  You're already ignoring 
that.)

If you'd like to ignore the rest, I'm not sure what real difference it would 
make.

> > Meanwhile, I have a small patch that provides this (from a user
> > perspective) now.  Working today.
>
> The point is that it's close enough to allnoconfig, so that it's IMO not
> worth it.

So far, this statement of pure opinion is the sum total of your technical 
arguments.

I've been working around kconfig for most of a year to do this functionality, 
until your recent changes broke what I'd been doing.  Your recent changes 
replaced the way I've been doing it with a new way of doing it, but I don't 
believe you had what I've been doing all along in mind when you did them.  
You primarily seem to have been interested in offloading decisions like 
allyesconfig not enabling broken drivers not expected to compile.  The fact 
that it's useful to me seems entirely accidental.

Are you saying you had something like miniconfig in mind when you made these 
changes?  If so, why was there no documentation?  Why was there no way to 
make a mini.config from a normal config?  Why was the user interface wrong in 
several different obvious ways that were easy to fix?  (You've already 
admitted that the stdout output is useless, and O= should take the config 
from the target directory.)

I was cheerfully using this functionality for eight months before you added 
allno.config, and what you did is closer but not a perfect fit for for what 
I've been doing.

> I'm trying to explain, what would be needed to do it properly, 

What exactly does the patch I posted do wrong?  (Other than the makemini.sh 
being a hack, but it's a hack to replace a complete absence of this feature.)

You seem to be simultaneously arguing that allnoconfig by itself is so good 
that it needs no change (despite there being no way at all to automatically 
create a miniconfig from a big .config), and that supporting miniconfig is an 
excuse for such an extensive rewrite that not just kconfig but kbuild must be 
adjusted to compensate.

Pick one.

> but either I failed to make myself understandable or you're not listening.

I feel _exactly_ the same way about you.

> > > > However, you seem to be forgetting that .config is read by the kernel
> > > > build infrastructure.  The tools are generating what _used_ to be a
> > > > human editable file.
> > >
> > > Oh, really?
> >
> > This is a slightly vague.  Is this "Oh, really?" arguing that it didn't
> > used to be a human readable format?
>
> At this point I was just wondering, whether you realize that I wrote the
> new kconfig stuff.

Why do you think I cc'd you?

> > > > I don't personally _care_ about the other config targets.
> > >
> > > Well, that's the problem, I do care about them.
> >
> > I think you're too focused on the implementation to see the users.  What
> > I'm trying to document is miniconfig, and as such any kallsyms target
> > allnoconfig is not _useful_.
>
> I'm actually quite interested in the needs of the users, but OTOH users
> have to realize that they are not always _exactly_ get what they want.
> Users often have very specific wishes and I try to provide a generic
> framework, which not only solves specific problems but also a broad range
> of problems, which often means to compromise as user needs can be very
> contradictory.

I'm trying to see how this applies.  Really I am...

> > > I want to keep it working without obfuscating it with thousands little
> > > features, so we have to figure out how to integrate it properly into
> > > the big picture.
> >
> > Do you have a suggestion that does not involve a complete rewrite of
> > kbuild over the next year or more?  I just posted one, and I've just
> > started work on another.
> >
> > I'm still not entirely certain you understand what I'm trying to
> > accomplish, and I'm sorry I can't make you understand why I need this. 
> > I'm not convinced that your "new config format" will be at all useful.
>
> I think I understand you quite well. Again, the basic functionality you
> want is already provided by allnoconfig

It was previously provided by
make allnoconfig && cat mini.config >> .config && yes "" | make oldconfig
Although that admittedly wasn't reliable because oldconfig is based on 
defconfig rather than allnoconfig, but yes "n" could go into an endless loop 
because oldconfig stupidly re-queries for numeric constants indefinitely.

> and the advanced features need a 
> bit more work than the few hacks you added to conf.c.

Why?  What advanced features?

> I like the idea of a minimum config, which e.g. users can send to
> developers or they can use for upgrading kernels, but this has to work not
> just for you, but also for the majority of users and this requires a
> better specification of how this feature should work in various
> situations.

If I wanted it to work just for me, would I have bothered writing up 
documentation first thing?  Would I have bothered posting the patch here at 
all?

What situations does the patch I posted previously not work in?

> bye, Roman

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Thursday 24 November 2005 19:48, Roman Zippel wrote:
> Hi,
>
> On Thu, 24 Nov 2005, Rob Landley wrote:
> > > On Mon, 21 Nov 2005, Rob Landley wrote:
> > > > Add "make miniconfig", plus documentation, plus the script that
> > > > creates a minimal mini.config from a normal .config file.
> > >
> > > The difference between miniconfig and allnoconfig is IMO too small to
> > > be really worth it right now.
> >
> > I disagree, fairly strongly.  The technical difference may be small, but
> > the conceptual difference is huge.
>
> I don't really disagree, a proper implementation of the concept would also
> be technically quite different. Hacking it into conf.c is the wrong to go
> (or to even start).

Hang on, I misread that last time.  You _don't_ disagree.

Sorry about that.

Ok, what's the best thing I can do to help get this implemented, working 
_with_ you rather than against?

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [PATCH] make miniconfig (take 2)

[Roman Zippel]

Hi,

On Fri, 25 Nov 2005, Rob Landley wrote:

> Ok, what's the best thing I can do to help get this implemented, working 
> _with_ you rather than against?

It's not exactly simple, as it requires some kconfig hacking.
Something relatively simply would be to change the miniconfig.sh script 
into a C program, where it would have to access to all the information to 
do the job fast and correctly.
I think it can even be done in a single pass over all the symbols, where 
boolean/tristate symbols are checked if they are already at the minimum 
value and string/hex/int values are compared with their default values.
Next step could be to add a variation of allnoconfig with better error 
checking (e.g. checking that all requested symbols have been set), the 
basic allnoconfig functionality is just a few lines of code, the fun is 
in the extras.

To further reduce the config size one could look at the dependecies, e.g.:

config FOO
	depends on BAR && BAZ1 || BAZ2

In this case FOO could also set BAR, but not BAZ1/BAZ2.
But this also requires a new frontend to read such a minimized config 
file and is quite a bit more complex.

bye, Roman

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 4626 bytes --]

On Sunday 27 November 2005 17:20, Roman Zippel wrote:
> Hi,
>
> On Fri, 25 Nov 2005, Rob Landley wrote:
> > Ok, what's the best thing I can do to help get this implemented, working
> > _with_ you rather than against?
>
> It's not exactly simple, as it requires some kconfig hacking.
> Something relatively simply would be to change the miniconfig.sh script
> into a C program, where it would have to access to all the information to
> do the job fast and correctly.

We are in agreement that miniconfig.sh sucks.  (I always saw it as a temporary 
measure, to be replaced with kconfig being able to write it out directly 
someday.)  Unfortunately, while I've sort of poked at kconfig before, I don't 
understand its dependency mechanism well enough to calculate the result I 
want reliably.

The current miniconfig.sh is based on a very simple (and slow) procedure, and 
even then I still haven't figured out why miniconfig.sh run on a straight 
allnoconfig insists that CONFIG_PM should be set.  (It correctly eliminates 
everything else...)

I can take a stab at making conf.c do this if you'd like.  (Or possibly 
confdata.c...)  Is the (admittedly sucky) shell script your main objection?

> I think it can even be done in a single pass over all the symbols, where
> boolean/tristate symbols are checked if they are already at the minimum
> value and string/hex/int values are compared with their default values.

Minimum value?

> Next step could be to add a variation of allnoconfig with better error
> checking (e.g. checking that all requested symbols have been set),

Um, I thought my patch did that.  If any unrecognized symbols were 
encountered, my miniconfig patch would report it and exit with an error by 
the simple expedient of making the warning count a global and checking it 
afterwards.  (I did a sort of -Werror for kconfig.)  If it attempts to set an 
unrecognized symbol, it would already generate a warning, and if the warning 
count is nonzero it bails out with an error at the end.  Seemed to work quite 
well, for me anyway...

What cases would that not catch?

(In theory, I could just has easily have done that part in a pure makefile 
change, copying mini.config to allno.config, running the existing allnoconfig 
suppressing stdout and capturing stderr to an environment variable, printing 
the content of the environment variable, and then exiting with an error if 
the environment variable isn't blank.  I just thought patching the .c code 
was the correct way to do it.)

> the basic allnoconfig functionality is just a few lines of code, the fun is
> in the extras.
>
> To further reduce the config size one could look at the dependecies, e.g.:
>
> config FOO
>  depends on BAR && BAZ1 || BAZ2
>
> In this case FOO could also set BAR, but not BAZ1/BAZ2.

Good point, but the existing format is 90% of the gain for 10% of the effort.  
Going from .config to miniconfig for my laptop's kernel, for example, goes 
from 1370 lines to 138 lines, almost exactly a 10x reduction.  And that can 
be done (admittedly badly) today, with the patch I posted.

Dropping that 138 down to 120, or even to 100, is a polishing step in 
comparison.  Do you think there are another 30 lines that could be trimmed 
out of that 138?  (Attached.)

Looking through it, I remember setting most if not all of of those symbols in 
menuconfig...

> But this also requires a new frontend to read such a minimized config
> file and is quite a bit more complex.

Right now, I have mini.configs that the existing infrastructure can read.  
Currently, creating a miniconfig by hand involves setting exactly the set of 
symbols that you would modify in menuconfig.  And conceptually, to me, that's 
what a miniconfig is.  Only the symbols indicating exactly the features the 
human wants to include.  This has the advantage of being understandable to 
said human.

This miniconfig is using the same symbol names as the existing config system 
(which was originally designed to be human readable, long ago), it's just 
eliminating unnecessary information (almost all dependency information, 
except for some menu-opening symbols), and being a lot more forgiving to 
human editing (while the existing .config explicitly says "don't edit" in a 
comment at the top).

I don't understand what advantage the new frontend that's quite a bit more 
complex would give here.  Which symbols would we then not have to specify?  
(Can you give me an example from any currently existing .config?)

> bye, Roman

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

[-- Attachment #2: mini.config --]
[-- Type: text/plain, Size: 2855 bytes --]

CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_EMBEDDED=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SHMEM=y
CONFIG_LBD=y
CONFIG_IOSCHED_CFQ=y
CONFIG_MPENTIUMII=y
CONFIG_X86_GENERIC=y
CONFIG_HPET_TIMER=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_I8K=y
CONFIG_MTRR=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=y
CONFIG_ACPI_IBM=y
CONFIG_ACPI_TOSHIBA=y
CONFIG_X86_PM_TIMER=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_PCI_MSI=y
CONFIG_ISA=y
CONFIG_PCCARD=y
CONFIG_CARDBUS=y
CONFIG_YENTA=y
CONFIG_BINFMT_ELF=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IEEE80211=y
CONFIG_IEEE80211_CRYPT_WEP=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_1284=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_CDROM_PKTCDVD=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_NETDEVICES=y
CONFIG_BONDING=y
CONFIG_TUN=y
CONFIG_NET_RADIO=y
CONFIG_IPW2200=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_UNIX98_PTYS=y
CONFIG_RTC=y
CONFIG_AGP=y
CONFIG_AGP_ATI=y
CONFIG_DRM=y
CONFIG_DRM_RADEON=y
CONFIG_VGA_CONSOLE=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_SB16=y
CONFIG_SND_INTEL8X0=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_UTF8=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_EARLY_PRINTK=y
CONFIG_4KSTACKS=y

Re: [PATCH] make miniconfig (take 2)

[Roman Zippel]

Hi,

On Sun, 27 Nov 2005, Rob Landley wrote:

> The current miniconfig.sh is based on a very simple (and slow) procedure, and 
> even then I still haven't figured out why miniconfig.sh run on a straight 
> allnoconfig insists that CONFIG_PM should be set.  (It correctly eliminates 
> everything else...)

It seems because ACPI takes itself too important and sets the default to y 
and this selects PM and prevents it from setting to n, until ACPI is 
reset. default and select is a really bad combination. :-(

> > I think it can even be done in a single pass over all the symbols, where
> > boolean/tristate symbols are checked if they are already at the minimum
> > value and string/hex/int values are compared with their default values.
> 
> Minimum value?

This is actually documented. :)
n - 0, m - 1, y - 2

> > Next step could be to add a variation of allnoconfig with better error
> > checking (e.g. checking that all requested symbols have been set),
> 
> Um, I thought my patch did that.  If any unrecognized symbols were 
> encountered, my miniconfig patch would report it and exit with an error by 
> the simple expedient of making the warning count a global and checking it 
> afterwards.  (I did a sort of -Werror for kconfig.)  If it attempts to set an 
> unrecognized symbol, it would already generate a warning, and if the warning 
> count is nonzero it bails out with an error at the end.  Seemed to work quite 
> well, for me anyway...
> 
> What cases would that not catch?

Symbols can be hidden by new dependencies.

> Good point, but the existing format is 90% of the gain for 10% of the effort.  
> Going from .config to miniconfig for my laptop's kernel, for example, goes 
> from 1370 lines to 138 lines, almost exactly a 10x reduction.  And that can 
> be done (admittedly badly) today, with the patch I posted.
> 
> Dropping that 138 down to 120, or even to 100, is a polishing step in 
> comparison.  Do you think there are another 30 lines that could be trimmed 
> out of that 138?  (Attached.)

Yes, some symbols are hidden behind a lot of dependencies, if a user wants 
to enable a new option, he only adds one new option and kconfig can try to 
figure out the missing options.

bye, Roman

Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

On Monday 28 November 2005 19:00, Roman Zippel wrote:

> > > I think it can even be done in a single pass over all the symbols,
> > > where boolean/tristate symbols are checked if they are already at the
> > > minimum value and string/hex/int values are compared with their default
> > > values.
> >
> > Minimum value?
>
> This is actually documented. :)
> n - 0, m - 1, y - 2

I understand that bit, but the problem with the single pass you suggested is 
that symbols can be set by dependencies (like the one afflicting CONFIG_PM), 
and those are neither off nor at their default, yet they're not actually 
required.

So a third criteria would be that this symbol's value is occluded by some 
other symbol.  (And "occluded" could either be "in a menu that's not open" or 
"set by somebody else's dependency".)

This starts sounding like a directed graph, and I am _not_ familiar enough 
with the kconfig structure to try to work it out yet.

I think, however, that "at default" (for allnoconfig's default, anyway) or 
"set by a dependency from another symbol" are the only two instances where we 
don't care about this value because it can be regenerated.  There's a corner 
case where the directed graph has cycles in it (two things that each switch 
the other on if they're enabled), but A) this is probably illegal already, B) 
we don't care which one we skip as long as there's no _redundant_ 
information.  Just be consistent (keep the first one).

How far off am I?

> > > Next step could be to add a variation of allnoconfig with better error
> > > checking (e.g. checking that all requested symbols have been set),
> >
> > Um, I thought my patch did that.  If any unrecognized symbols were
> > encountered, my miniconfig patch would report it and exit with an error
> > by the simple expedient of making the warning count a global and checking
> > it afterwards.  (I did a sort of -Werror for kconfig.)  If it attempts to
> > set an unrecognized symbol, it would already generate a warning, and if
> > the warning count is nonzero it bails out with an error at the end. 
> > Seemed to work quite well, for me anyway...
> >
> > What cases would that not catch?
>
> Symbols can be hidden by new dependencies.

Something gets enabled that then disables other things?  Hmmm...

I've been thinking of things in terms of visibility.  The menu this symbol 
lives in either is or isn't open, and I can't set the symbol unless its menu 
is open.  If two different symbols control visibility for the same menu, it's 
still really that the menu has one guard symbol and that dependencies of 
other things are messing with that guard symbol.  I think.

The way I've been thinking about miniconfigs is that each symbol in a 
miniconfig is an action changing the default state.  When you read in a 
miniconfig, you start with all symbols at default allnoconfig values, and 
then make this list of changes to that state (in order) letting the 
dependencies do their thing with each change.  (This maps to what a user 
would do in menuconfig, selecting X, Y, and Z in this order.  I could write 
it down on a piece of paper for the user, so why can't the machine do it for 
me?)

So really a miniconfig can't specify an inconsistent state, it can only be 
redundant.  (It can switch on things that later get switched off again by 
dependencies on later symbols.)  And all that means is the miniconfig is 
longer than it needs to be, which could easily be the case if a human made it 
by hand.  Perhaps some kind of warning would be a good idea ("symbol 
CONFIG_BLAH reverted by CONFIG_BLAH"), if it was easy to implement (perhaps 
by tagging the "manually" selected symbols, ones which the miniconfig had 
already explicitly specified a value for).  But not a show-stopper to me.

> > Good point, but the existing format is 90% of the gain for 10% of the
> > effort. Going from .config to miniconfig for my laptop's kernel, for
> > example, goes from 1370 lines to 138 lines, almost exactly a 10x
> > reduction.  And that can be done (admittedly badly) today, with the patch
> > I posted.
> >
> > Dropping that 138 down to 120, or even to 100, is a polishing step in
> > comparison.  Do you think there are another 30 lines that could be
> > trimmed out of that 138?  (Attached.)
>
> Yes, some symbols are hidden behind a lot of dependencies, if a user wants
> to enable a new option, he only adds one new option and kconfig can try to
> figure out the missing options.

You mean enabling a symbol in a closed menu would open the menu (but leave 
everything else in it disabled, rather than at default values)?  So 
miniconfig wouldn't have to specify guard symbols at all anymore?

That would be nice.  I suspect there are guard symbols that are also 
functional (CONFIG_SCSI comes to mind), so the rule would have to be 
something like guard symbols are only discardable when something in the menu 
they protect _is_ specified.

However, that could go in as a future enhancement, because it falls under 
"specifying redundant symbols".  A miniconfig that did switch on the menus 
(which would then be selected by a later dependency anyway, once the config 
reading logic was upgraded) would still work in to configure a newer kernel 
with a smarter configurator, wouldn't it?

> bye, Roman

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

Re: [PATCH] make miniconfig (take 2)

[Roman Zippel]

Hi,

On Mon, 28 Nov 2005, Rob Landley wrote:

> I understand that bit, but the problem with the single pass you suggested is 
> that symbols can be set by dependencies (like the one afflicting CONFIG_PM), 
> and those are neither off nor at their default, yet they're not actually 
> required.

Setting everything to n can still be done in single pass, but that 
requires working around the normal API and setting the values directly, 
e.g.:

	for_all_symbols(i, sym) {
		if (!(sym->flags & SYMBOL_NEW))
			continue;
		switch (sym->type) {
		case S_BOOLEAN:
		case S_TRISTATE:
			sym->user.tri = no;
			sym->flags &= ~SYMBOL_NEW;
		}
	}

Now you only need to flush the old precomputed values 
(sym_clear_all_valid()) and you're done.

> This starts sounding like a directed graph, and I am _not_ familiar enough 
> with the kconfig structure to try to work it out yet.

The kconfig data is a directed acyclic graph, which allows to do most 
operation deterministically in a single pass.
The problem is to transform the data from a valid state to another valid 
state. The normal API allows only changes which keep the data in a valid 
state (e.g. you can't set a not visible symbol), but it's possible to 
bypass this and set multiple symbols, flush the old state and a new state 
will generated which is consistent with the Kconfig rules.
Currently only conf_read() does this, i.e. you can throw pretty much any 
.config at it and it will generate a valid (but not necessarily useful) 
config from it.

> > Symbols can be hidden by new dependencies.
> 
> Something gets enabled that then disables other things?  Hmmm...
> 
> I've been thinking of things in terms of visibility.  The menu this symbol 
> lives in either is or isn't open, and I can't set the symbol unless its menu 
> is open.  If two different symbols control visibility for the same menu, it's 
> still really that the menu has one guard symbol and that dependencies of 
> other things are messing with that guard symbol.  I think.
> 
> The way I've been thinking about miniconfigs is that each symbol in a 
> miniconfig is an action changing the default state.  When you read in a 
> miniconfig, you start with all symbols at default allnoconfig values, and 
> then make this list of changes to that state (in order) letting the 
> dependencies do their thing with each change.  (This maps to what a user 
> would do in menuconfig, selecting X, Y, and Z in this order.  I could write 
> it down on a piece of paper for the user, so why can't the machine do it for 
> me?)

This is not how it works (see above), reading the .config and user 
interface changes are two different things.
After the config has been read, the data is brought into a consistent 
state, which may mean the actual symbol value may be different, as they 
are limited by their dependencies.

> > Yes, some symbols are hidden behind a lot of dependencies, if a user wants
> > to enable a new option, he only adds one new option and kconfig can try to
> > figure out the missing options.
> 
> You mean enabling a symbol in a closed menu would open the menu (but leave 
> everything else in it disabled, rather than at default values)?  So 
> miniconfig wouldn't have to specify guard symbols at all anymore?
> 
> That would be nice.  I suspect there are guard symbols that are also 
> functional (CONFIG_SCSI comes to mind), so the rule would have to be 
> something like guard symbols are only discardable when something in the menu 
> they protect _is_ specified.

There are no special guard symbols, so if a SCSI driver is requested, this 
means CONFIG_SCSI needs to be set.

bye, Roman

Re: Quick and dirty miniconfig howto, with feature suggestions.

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

On Thursday 17 November 2005 06:29, Rob Landley wrote:
> --- What is a miniconfig?
>
> A new feature of 2.6.15 lets you use miniature configuration files, listing
> just the symbols you want to enable and letting the configurator enable any
> dependencies to give you a valid configuration.
>
> To make it work, create a mini.config file and run allnoconfig (to create
> a .config file with all unspecified symbols switched off) with the extra
> argument "KCONFIG_ALLCONFIG=mini.config".

And here's a shell script that will automatically create a mini.conf from a 
standard .config file.

It does this via the simple expedient of trying to remove each line and seeing 
which ones make any difference to the generated .config.  (This means it runs 
make allnoconfig about 1300 times.  This is very very slow, so it displays a 
progress indicator.)

To use the script, go into the kernel source directory, create your .config 
file (via menuconfig or however), rename that .config file to something else 
(like "myconfig"), then run the script like so:

./miniconfig.sh myconfig

(Note you still have to be in the directory where the script can run "make 
allnoconfig".)  When it finishes, you should have a mini.conf containing the 
minimal set  of lines necessary to specify that configuration via
"make KCONFIG_ALLCONFIG=mini.config allnoconfig".

I'm sure there's a better way to do this, but this works now.

Rob

[-- Attachment #2: miniconf.sh --]
[-- Type: application/x-shellscript, Size: 906 bytes --]