new applet: devmem

[Rob Landley]

On Wednesday 29 October 2008 07:25:42 Denys Vlasenko wrote:
> On Sun, Oct 26, 2008 at 11:28 PM, Rob Landley <rob at landley.net> 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