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