[Aboriginal] miniconfig-busybox

[James McMechan]

> Date: Mon, 5 Dec 2011 12:26:52 -0600
> On 12/02/2011 08:24 PM, James McMechan wrote:
> >> Yeah, but should it expect to find them in $SOURCES (where all the other
> >> files would be checked into source control, but these wouldn't) or at a
> >> location specified in config? The overlay mechanism for extra root
> >> filesystem files is config based for the same reason, mixing tracked and
> >> untracked files in the same directory is untidy.
> >
> > if you had a config directory I would have aimed for there,
>
> 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


> 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


> 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++

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.

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.


> >> Long-term I want to move to toybox and just not HAVE buckets of
> >> extraneous crap needing to be disabled...
> >
> > It would be very nice.
>
> I'm working on it. Just did a blog entry about what record-commands
> says I need for the build. (Might not get to publishing it until
> tomorrow, needs some cleanup.)
>
> It boils down to me needing to add this to toybox in order for it to be
> able to replace busybox in aboriginal linux (at least for the i586
> build, I need to check other targets, and I'm not quite sure what LFS
> needs...):
>
> awk basename bzip2 chmod chown cmp cut date dd diff dirname
> egrep env expr find grep gzip head hostname id install ld ln ls
> mkdir mksquashfs mktemp mv od patch readlink rm sed sh
> tail tar touch tr uniq wget whoami xargs
>
> About half of those are low-hanging fruit anyway...
>
> >>> there are prettier layouts though
> >>> done=0
>
 >>> [ $done -eq 0 -a -e "${SOURCES}/mini-busybox" ] &&
 make allnoconfig KCONFIG_ALLCONFIG="${SOURCES}/mini-busybox" &&
 done = 1
> >>> [ $done -eq 0 -a -e 
"${SOURCES}/trim-busybox" ] && make allyesconfig 
KCONFIG_ALLCONFIG="${SOURCES}/trim-busybox" && done = 1
> >>> [ $done -eq 0 ] && make defconfig && done = 1
> >>> [ $done -ne 0 ] && \
> >>
> >> 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 would still like it able to run under
> > ash or other shells from the days of chipped flint systems.
>
> The current aboriginal linux scripts don't. They use
> blah/{curly,bracket} wildcards and <(this kind) of pipe where the
> command gets a filename it can read from to get the output of a command
> (and there's a >(version) that's a file that outputs _to_ that command),
> so you can do:
>
> diff -u <(blah | sort -u) < (blah2 | sort -u)
>
> And so on...
>
> 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... less small and less simple

dash is a odd duck, I never quite understood its purpose.

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

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


> Remember: I didn't remove the -i option from uses of sed, I extended
> busybox sed to cope with -i. I haven't seriously banged on busybox in
> years, but now I'm back throwing scraps of spare time at toybox.
>
> >>>> I'm also back to working on toybox, which means testing toybox, which
> >>>> means getting toybox and busybox to install alongside each other and
> >>>> gradually reduce the number of busybox commands I'm using.
> >>>
> >>> Personally, I like building up from the bottom, rather than trying to trim
> >>> the fat from the top...
> >>
> >> When you're migrating a system that currently works by replacing
> >> components, you have to build the new thing while dismantling the old,
> >> so you wind up doing both...
> >
> > 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

> This is a long email, I'll have to finish replying to it later...
>
> Rob

 		 	   		  
 1323398047.0