Invalid options segfault?

Rob Landley rob at landley.net
Fri Nov 7 19:01:19 UTC 2008


On Thursday 06 November 2008 19:33:12 Denys Vlasenko wrote:
> > I already figured out another way to get the behavior I want, by avoiding
> > the useless defconfig entirely and instead using a driedfrogpills file to
> > impose sanity upon allyesconfig via the KCONFIG_ALLCONFIG infrastructure.
> >  (I posted that yesterday, in the message titled "make saneconfig".) 
> > That way all other new options that show up in new versions of busybox
> > (mostly features) automatically get enabled, and I can switch off any new
> > ones that cause me problems by adding them to the driedfrogpills file.
>
> Yes, I would do the same. Depending on someone else's .config is a bit too
> fragile.

That's what I thought, too.  Here's a summary of my earlier reasoning, for 
future reference:

People who have never used busybox before, and want to build it from source 
and try it out are looking to answer specific questions: does it work with 
their toolchain and run on their target system, and does it provide all the 
functionality they need?  They want to get it to build and test the busybox 
implementation of the various commands.  Trimming it down to a specific size 
comes later.

People unfamiliar with busybox should have an easy way to build a version that 
demonstrates everything it can do.  In theory, that means they should have an 
easy way to build a version with every feature enabled, so they only have to 
fight with their toolchain and libraries and kernel and bootloader and such 
_once_ to get a working binary, and then ask "has it got X, and does that X 
do what I need" by actually trying it.

Unfortunately, if you build an "allyesconfig" version, the result isn't 
usable.  You have to switch off the debug options or else the output is 
polluted with debug messages and things like init don't behave in a realistic 
manner.  Beyond that, some options require a specialized environment to run 
in: If you enable PAM then it won't even compile on a system that hasn't got 
PAM set up (and most targets don't), and selinux is similar and even more of 
a pain to set up a working context for.

So the configuration produced by "allyesconfig" is not actually _sane_.  You 
have to be fairly familiar with busybox in order to disable enough stuff from 
allyesconfig to get to the point where you can demo busybox to somebody 
unfamiliar with it.

But beyond the things that prevent it from building or running in a fairly 
generic environment, we shouldn't disable anything _else_ because we don't 
know what people will actually want to use.  We don't _know_ if they need to 
use an old tape drive or floppy drive.  (If we honestly think nobody will 
ever use those features, then we should deprecate them and remove them from 
busybox entirely.  If somebody _might_ use them, and the only harm enabling 
does is to make the busybox binary bigger, then they should be available in 
the demo version.)

The demo version is also the one the test suite is most likely to get run 
against, because everybody can "make defconfig && make test".  That's as much 
to make sure that their _environment_ can build and run busybox as to test 
out busybox itself.  That's an easy test of the toolchain, C library, and 
kernel of your target system.

Any feature that gets removed from defconfig won't get nearly as much testing, 
so if we yank things like dpkg support we're not sure they'll even compile 
for things like coldfire, blackfin, or microblaze.  Things that we may not 
have a decent test environment for lying around, due to a lack of QEMU 
support for the suckers.  We want as much as possible in defconfig to 
minimize bitrotting.

That was my theory, anyway.  A busybox configuration HOWTO wouldn't be bad 
either, but writing one would involve extensively referencing SUSv3 and Linux 
From Scratch.  (I'm pondering writing an Embedded Linux From Scratch.  How to 
make an LFS system based on BusyBox and uClibc.  The main thing stopping me 
so far is I dunno what the LFS upstream template is based on (docbook?) and 
what tools they use to spit out the html vesion.  Plus the procedures to 
contribute it back upstream to linuxfromscratch.org.  Simply haven't looked 
into it yet.  My todo list runneth over...)

If you want to merge the driedfrogpills file and add a "make saneconfig", I 
could whip up a patch, but I don't know what purpose that leaves for "make 
defconfig"...

Rob



More information about the busybox mailing list