defconfig removal question

[Rob Landley]

On Saturday 11 February 2006 14:08, Bernhard Fischer wrote:
> Hi Rob,
>
> Is see you removed the defconfig file (partly).

Yup.

My rationale here is that there are only two really interesting starting 
points: allnoconfig and allyesconfig.  The whole point of being this 
configurable is that users' needs are different, and attempting to guess 
which specific applets somebody actually needs is doomed to failure, so we 
shouldn't try.

The problem is that although allnoconfig is a great starting point for users 
on the buffet plan (I want this, and this, and this...), allyesconfig isn't.  
You have to disable a lot of things to get something sane.  (A debug version 
of busybox statically linked with libc but dynamically linked against 
libbusybox.so...)

Previously, allyesconfig was disabling options to get a sane configuration, 
and over time, allyesconfig was diverging farther and farther from a true 
"allyesconfig".  This meant we didn't get coverage testing of the stuff that 
was disabled, like debug builds or selinux.  If they broke, we wouldn't 
notice.  Eventually I went "ok, enough" and forked it, bumping defconfig and 
putting back an "allyesconfig" that enables everything except 
cross-compiling.

So the new defconfig should be the maximum sane config, starting with 
allyesconfig and remove things that people should manually select if they 
really want them.  This would include anything that requires a nonstandard 
configuration to use (such as like selinux or devfs support), things that 
just aren't part of normal use (like debug symbols), and packaging choices 
like static linking or libbusybox.so (and when it's added, make standalone; 
you want that, you select it).

The idea is, they can go "make defconfig" and then immediately test out 
busybox, throw it in a prototype answer the question "does this version of 
busybox support all the functionality I need?"  Then later they can remove 
unnecessary stuff to save space, once they have a better idea of what it is 
they need.

The other side of this is I loosened up allyesconfig to actually _be_ 
allyesconfig.  The only thing that's disabling now is "use cross compiler".  
This should at least compile, and the fact we haven't gotten coverage testing 
of some of this code for a while (because allyesconfig doesn't enable 
selinux, for example) means some stuff bit-rotted.

From a maintainability standpoing, not having to update the .defconfig file 
anymore counts as a win.  Now when we add a new feature, it winds up on by 
default so people can try it out easily (and if that's a bad thing we can add 
it to the filter list in the makefile).

As a point of pride, I'm trying to keep defconfig under a megabyte, on Intel, 
built with a reasonably recent version of gcc.  Going forward, that might put 
a reasonable feature limit on the project.  (You want to add a new feature?  
Shrink something else down...)  Dunno how that'll work out in practice...

> You forgot to remove the copying around of the file in the two *config
> targets; I fixed that in my upcoming simplification of the buildsystem.

I'm slowly coming up to speed on the makefiles, but the operative word here is 
"slowly".

> A question: After you removing defconfig, a simple "make menuconfig",
> which is the default in a pristine co, the user now gets basically an
> allnoconfig setting to start with.

I've been running "make distclean && make defconfig" by hand.  I have no 
problem with that being the default.

> i.e. start with defconfig, or was moving to allnoconfig done on purpose?

Nope, that behavior change was incidental.  Feel free to fix that.

> Thanks for clarification and opinions,
> Bernhard

Thanks,

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