[Aboriginal] miniconfig-busybox

[Rob Landley]

On 12/02/2011 08:24 PM, James McMechan wrote:
> 
>>>>> I saw David Seikel's comments about still being interested in trim-config
>>>>> Here is how I use mini-config with busybox, it is not hard
>>>>> though I have not yet gotten the auto build stuff to include the aboriginal
>>>>> tarball and the package directory in my initramfs
>>>>
>>>> There was an initramfs bug recent-ish-ly, are you using a version after
>>>> http://landley.net/hg/aboriginal/rev/1366 ?
>>>
>>> I was using Aboriginal-1.1.0 but am having a few problems
>>> I seem to remember it working fine with 1.0.1, 1.0.0 and 0.9.11
>>> now for some reason the patch command is failing, I will need to double
>>> check the config file for busybox it may have a new knob in config somewhere
>>
>> I fixed the toybox/busybox patch command in August and again in October,
>> possibly you're hitting one of those bugs.
>>
>> I need to get the next release out, but I keep hoping I can beat some
>> sense out of sparc first. (It's almost building LFS! Progress!)
>>
>>>>> --- busybox.orig 2011-11-27 05:41:26.000000000 -0800
>>>>> +++ busybox.build 2011-11-27 16:19:20.000000000 -0800
>>>>> @@ -5,7 +5,8 @@
>>>>> # Build busybox
>>>>>
>>>>> #make allyesconfig KCONFIG_ALLCONFIG="${SOURCES}/trimconfig-busybox" &&
>>>>> -make defconfig &&
>>>>> +#make defconfig &&
>>>>> +make allnoconfig KCONFIG_ALLCONFIG="${SOURCES}/mini-busybox" &&
>>>>
>>>> I need to provide a way to select this, do a defconfig if no busybox
>>>> config is provided, otherwise use that. Probably some kind of config
>>>> setting.
>>>
>>> well there is the classic method to try all three,
>>
>> 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.

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.

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)...

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

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.

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

Rob

 1323109612.0