On Wednesday 29 October 2008 07:25:42 Denys Vlasenko wrote: > On Sun, Oct 26, 2008 at 11:28 PM, Rob Landley <[EMAIL PROTECTED]> wrote: > > On Sunday 26 October 2008 08:26:29 Bastian Blank wrote: > >> > +config DEVMEM > >> > + bool "devmem" > >> > + default y > >> > >> Why default y? This is no generic tool. > > > > When did defconfig stop being the maximum sane configuration, by the way? > > I suspect there was a policy shift, I just didn't see the > > announcement... > > > > And what criteria are you using to determine what is and isn't a generic > > tool? Defconfig includes things like taskset and inotifyd that don't even > > build on a lot of non-x86 architectures (even with a current kernel). > > When's the last time anybody actually used "mt"? Who decided that dkpg > > wasn't "generic" but rpm was? findfs is disabled in defconfig but > > fdformat is enabled (in 2008)? > > Thanks for pointing out inconsistensies. I fixed a few. > Keep complaining please, this helps me to make it better.
I'm trying to understand the philosophy. Three years ago we had a swiss cheese defconfig that was useful to nobody. I switched it to defconfig enabling every piece of functionality that was expected to work out of the box, because that was a good starting point for people who wanted to "start with everything" and pare it down to fit in the space they had available. (The other obvious starting point is allnoconfig, starting with nothing and adding what they need.) Making such a "maximum sane configuration" defconfig involved switching off numerous debug options that "allyesconfig" enabled. If "allyesconfig" left these on it didn't build an actually usable configuration and thus wasn't a good starting point for configuring your own custom configuration, it was just there for testing purposes. But anything that allyesconfig switched off never got build tested and several of them didn't work. It meant allyesconfig was just there for testing purposes, so we needed defconfig as the starting point for people to actually create their own "start with everything and chop it down" configs. If the "start with everything" config _doesn't_ include everything, then lots of people never notice busybox even _has_ that applet unless somebody points it out to them. (That was another common complaint.) But what defconfig _didn't_ do was try to figure out what commands people did and didn't want to use. If a command was useful to nobody then it shouldn't be _in_ busybox. If defconfig switches off a command that's useful to somebody then it's not a good display of all busybox's functionality. You're going back to the swiss cheese defconfig. You're back to trying to guess which commands "they" will want to use without knowing who "they" are, and we know from experience that approach simply doesn't work. No two people want the same sets of commands. Trying to come up with a one size fits all configuration that includes linksys routers and network boot images for beowulf clusters is a losing proposition, and _any_ attempt to do so will over time deteriorate to "make randconfig" useless to the majority of the userbase. That's not really my problem, though. I don't really care about your personal make randconfig, you're the maintainer and can include anything you want. I want to know how to get back the "maximum sane configuration" option, now that you've removed it. The "allyesconfig minus debugging options that break stuff and/or provide zero actual functionality". The good starting point for the "start with everything and pare it down" approach. How do you suggest I get that back, other than maintaining my own config by hand? Rob _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
