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 _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
