Re: [PATCH] make miniconfig (take 2)

[Rob Landley]

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