[Aboriginal] miniconfig-busybox

[Rob Landley]

Sorry for the delay in answering this, I'm trying to extend your
baseconfig into something that's got everything _I_ need switched on
(including for download.sh and the LFS build), and then I'm checking it
in as the new default.  I can then do a "build busybox defconfig" as a
native-build hdc image.

So far I have:

1) Your experimentally determined list
2) the record-commands lists for aboriginal and LFS builds.
3) The list of commands in the SUSv4 utilities page.

I'm thinking some combination of these three still removes around 100
commands from busybox.

On 12/08/2011 08:34 PM, James McMechan wrote:
>> Hmmm... I don't want to have too _much_ configuration. A hammer isn't
>> a better hammer if it's got 37 switches you have to flip before pounding
>> nails.
> 
> Well yes, but I also have half a dozen different hammers in the tool box next
> to the computer so since they can't be configured I need multiples

"Do one thing and do it well."

I'm trying to remember if that quote is from Ken Thompson or Brian
Kernighan.  It's one of the original unix guys, anyway...

>> I had the target directories (which I eventually cleaned up into
>> individual target files for most of them), because each target is
>> somewhat different and I wanted a single place to collect all those
>> differences.
>>
>> The stuff in "sources" is the stuff that's the same for all targets.
>> I added an "overlay" capability so people didn't have to extensively
>> fiddle with sources/root-filesystem.
>>
>>> SOURCES is where the trimconfig used to reside.
>>> Also I would expect that mini-config & company
>>> would be checked in.
>>
>> Back then trimconfig was "what all targets needed". It belonged in
>> sources for the same reason the kernel and uClibc baseconfigs do: it was
>> generic.
> 
> I thought of it as this stuff breaks on at least one target

Trimconfig itself contained stuff that broke on at least one target and
thus needed to be removed for busybox to build the same way on all
targets.  What the trimconfig _produced_ was a defconfig that worked on
all targets.  I then got defconfig itself to work on all targets, but it
keeps bloating and breaking...

>> Then I got enough changes pushed upstream into busybox that defconfig
>> could work for all targets, and from the point of view of _this_ project
>> using defconfig was simpler than specifying a config that could get out
>> of sync with what upstream was doing. (Which is inherent in trimconfig:
>> a delta against upstream.)
>>
>> That said, a busybox baseconfig makes sense from a design standpoint.
>> The minimal native development environment capable of rebuilding itself
>> under itself: stuff like linux from scratch has to bootstrap its way up
>> (possibly by building busybox defconfig first)...
> 
> In general I dislike negative options such as NO_CPLUSPLUS and would
> much rather have a CPLUSPLUS=1 in the config file by default
> which would then be commented out to turn off C++

I see your point, but each config option is at its default value when
it's blank, thus to set config back to its default values comment
everything out.

This means that anything that defaults to "on" but which can be removed
needs a negative option.  (I'm not saying that's a great way to do it,
I'm saying that's the reasonably consistent rationale behind the way it
currently is.)

> This leads to my strong preference for the additive mini-config, it is much
> easier for me to think about sections added together to build everything desired,
> e.g. first part has the options needed to build aboriginal the second has
> what is needed to run under qemu, say a third for LFS build requirements
> it could be a single text file with commented sections or a series of separate files
> catted together to provide all the desired features.

If you're creating a build environment on target, LFS is a good (but not
perfect) high water mark (since if all else fails, you can recreate LFS).

The defconfig was "everything busybox can possibly provide that might
help", which was a defensible design decision but brittle as far as
building it goes and unstable because upstream keeps adding stuff.

The problem with "the absolute minimum set of commands we need" is it's
a bit brittle the other way (we didn't know we needed X), but that just
means we need a lot of testing, and that's what "build each target
through to the end of LFS" is for...

If you're creating some other kind of target system, I intentionally
have no opinion on _what_ you'll need in it, it may just be three commands.

> That way if I want to build gentoo instead of LFS I would just change
> that section and avoid cluttering the environment with low usage commands
> e.g. why exactly when building a minimal system do I need ifenslave
> if I need that I would turn it on later.

LFS builds m4 before building things that need m4.  If you can do that
natively, you don't need more stuff from busybox.  If you CAN'T do that
natively, the build environment we're producing is defective.

In theory, you can build a defconfig busybox on target as part of your
bootstrapping.  I'm not personally interested in having a bunch of
collated config chunks for special-purpose stuff (although it's trivial
to add on top of the infrastructure we're providing).

>>>> Probably an if/else staircase. That's what they're for.
>>>
>>> I don't remember if classic shell had else,
>>
>> Yup, SUSv3 and SUSv4.
> 
> I appear to be a old fogey, I still remember when we upgraded to csh and later ksh
> and the upgrade guide for X10 to X11, so my standards of what is a "old" shell
> are a bit out of date.

I'm providing a C99 compiler and a 3.x kernel.  I'm not providing a 2.0
kernel, a c89 compiler, and libc5.

SUSv4 isn't perfect (_why_ does it still include "ed" and "sccs"?) but
it's reasonably straightforward to support, and there are no obvious
alternatives: the same standard got approved as IEEE posix, open group
base specifications, and single unix standard, so I can shut 'em all up
with one pass.


>> Probably other stuff. I intend to write a shell that can cope with all
>> this, not strip down my script to be cripped for the Defective Annoying
>> SHell in bash.
> 
> 
> bourne shell was small and simple, bash is um...

It's from the gnu/dammit project.  I intend to replace it, just not this
week.  In the meantime, sticking with an old version reverses a bunch of
gnu "upgrades" that make it bigger and slower for no obvious reason.

> less small and less simple
> dash is a odd duck, I never quite understood its purpose.

Defective, Annoying SHell.

> looking at "man sh" it appears feature creep has been busy

Shell command line options:
  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html

Shell scripts:
  http://pubs.opengroup.org/onlinepubs/9699919799/idx/shell.html

Plus I did a lot of random research about what shells do and need,
searching my blog for toysh finds lots of things like:

  http://landley.net/notes-2007.html#19-10-2007

But tackling the shell comes after filling in the toybox command list
rather a lot...

> shell history, vi line editing mode and others have wandered into the shell

1) If you build bash 2.05b on a system that hasn't got curses, it won't
include history or command line editing.  (Which is kinda painful.)

2) DOS had shell history (doskey) so this predates the transition from
16-bit to 32-bit hardware.

3) we have cursor keys now, along with home/end, del and backspace, and
page up and down.  All standardized for about 30 years.  I'm happy to
rely on them being there.

>>> I was thinking that if you don't have the extra 100 commands from busybox
>>> the failures might be shorter. e.g. turn off od in busybox turn on in toybox
>>> test and repeat
>>
>> I was pretty much planning on doing that anyway. :)
>>
>> Although there's a cheap and easy way to do this: install toybox first,
>> then have the busybox installer simply fail to create symlinks when they
>> already exist.
> 
> or just have the toybox installer not overwrite the file behind a symlink
> when it exists already and create a new symlink instead

It's "ln -sf" either way.

One of the toybox ideas I managed to shove upstream is getting the darn
project to list the links to create, so you can do:

  for i in $(busybox --list); do ln -sf busybox $i; done

The toybox --list gives paths, which I can chop out with sed but I think
a non-path version would be good to.  It's a todo item...

Rob	   		


 1323713874.0