Invalid options segfault?

[Rob Landley]

On Wednesday 05 November 2008 20:19:50 Denys Vlasenko wrote:
> On Tuesday 04 November 2008 23:22, Rob Landley wrote:
> > On Tuesday 04 November 2008 12:00:33 Vladimir Dronnikov wrote:
> > > One more issue: when compiling sqlite I started to get the error:
> > > BUILD    sqlite
> > > awk: ./mkopcodeh.awk:117: Math support is not compiled in
> >
> > That's because Denys removed CONFIG_FEATURE_AWK_LIBM from defconfig,
> > which broke this.
> >
> > Sigh, defconfig has become useless as a "start with everything and remove
> > stuff" base.
>
> I do not break stuff on purpose. I do not want you or anybody else
> to have bad experience from busybox.
>
> But knowing what defconfig is supposed to be, as of now
> requires telepathic powers. Does it carry any explanation, say,
> in its header? No:
>
> # Automatically generated make config: don't edit
> # Busybox version: 1.13.0.svn
> # Wed Oct 29 13:15:09 2008

I left a comment in the makefile, in SVN 13879:

# defconfig is allyesconfig minus any features that are specialized enough
# or cause enough behavior change that the user really should switch them on
# manually if that's what they want.  Sort of "maximum sane config".

You removed this comment in svn 16349.  I thought it was an intentional policy 
change?

> Until very recently, I did not even realize you use defconfig
> in your work and thus have some expectations about it.

I don't think anybody uses defconfig in their work anymore, the current one is 
kind of useless precisely _because_ you need telepathy to understand its 
purpose and precognitive abilities to know how it'll change next release.

> If you want defconfig to obey some rules, let's formulate
> what these rules are, put them into defconfig's comment,
> and be done with it.

I put them in the makefile's comment at the point it generated defconfig.  I 
also posted repeatedly about it here on the mailing list at the time I did 
it, explaining my rationale.  (You're free to disagree with that, it's your 
ballgame now.  But I don't know how I could have been clearer at the time.)

I already figured out another way to get the behavior I want, by avoiding the 
useless defconfig entirely and instead using a driedfrogpills file to impose 
sanity upon allyesconfig via the KCONFIG_ALLCONFIG infrastructure.  (I posted 
that yesterday, in the message titled "make saneconfig".)  That way all other 
new options that show up in new versions of busybox (mostly features) 
automatically get enabled, and I can switch off any new ones that cause me 
problems by adding them to the driedfrogpills file.

In my experience, users create one of three configurations: either 
allyesconfig and trim it down, allnoconfig and work up, or go through 
menuconfig and examine every option.  People who use a pre-supplied 
configuration rather than making one themselves tend to get it from their 
distro (gentoo embedded, scratchbox, their vendor board support package, 
etc).  Most of these guys don't compile busybox themselves.  There _isn't_ a 
common configuration between distros, no two distros seem to want quite the 
same config.

Right now, there's no good starting point for people who want to start with 
everything and pare it down rather than start from zero (allnoconfig) and 
work up.  The result of allyesconfig doesn't _work_, not unless you configure 
selinux on your system, have the pam headers set up on your host so it'll 
compile, don't mind strange debugging behavior...

Rob