PLATFORM_LINUX is evil

Rob Landley rob at landley.net
Thu Feb 24 02:16:11 UTC 2011


On 02/23/2011 07:24 PM, Denys Vlasenko wrote:
> On Wednesday 23 February 2011 06:16, Rob Landley wrote:
>> So if you start with "allnoconfig" and look to see what applets you can
>> enable, things like "mount" don't exist for you unless you know to look
>> for them.  This adds a new layer of black magic and a-priori knowledge
>> required in order to build busybox.  That's not a good thing.
> 
> Istead of "depends on PLATFORM_LINUX", we can use "select PLATFORM_LINUX".
> 
> Then BSD people will come complaining that they can't easily select
> a config without inadvertently turning on linux-specific bits...

In which case the people who are requesting new functionality busybox
doesn't currently support come complaining to us about things they can
fix.  I don't see the downside there.

Also, BSD has a Linux emulation layer:

http://www.openbsd.org/faq/faq9.html#Interact
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/linux-emulation/index.html
http://docs.freebsd.org/doc/2.1.7-RELEASE/usr/share/doc/handbook/handbook227.html
http://www.linux.com/archive/articles/53055

And so on.

>> Busybox has always been a Linux program.  Pretending it's not at least
>> _primarily_ a Linux program is silly.  Anything that makes it harder to
>> use on Linux is _immensely_ counterproductive.  If you're trying to use
>> it on anything other than Linux, we have to assume you're an expert and
>> when it breaks you get to keep the pieces.
>>
>> If you really felt the need to have such a symbol, it would have made
>> more sense for it to have no effect when off and remove things when it
>> was switched on, so it didn't break allnoconfig.
> 
> I tend to avoid "negative" config symbols (and any kind of variables
> in general), because resultant constructs of the "if not not_foo ...."
> form are hard to read.

Agreed.  But in this case, the current impact on allnoconfig is a bigger
problem.

A negative config symbol isn't necessarily the best solution, the
"selects" thing might be a good way to go if you can work out how to
make that work.  If all you're trying to do is annotate which applets
require Linux rather than just posix, selects does that.

>> We've got plenty of 
>> symbols such as CONFIG_SELINUX that render busybox unbuildable by normal
>> humans when enabled, which is why "allyesconfig" is useless
> 
> You are right. Allnoconfig, allyesconfig and randconfig are useless
> (in some sense of the word), they need to be sanitized prior to use.
> See scripts/randomtest for an example.

Up until this change, allnoconfig wasn't useless.

Randconfig is always useless.  Way back when I hijacked defconfig to be
the maximum sane configuration so it was an allyesconfig replacement.
So the two entry points were allnoconfig (start with nothing and add
just what you need) and defconfig ("start with full distro and remove
what you don't need").

This change damaged one of those two entry points.  It stopped being
obvious how to add things like "mount" (or that we even supported it at
all), which tend to be things people need to set up a Linux system.

It makes embedded Linux systems harder to set up with busybox, which is
pretty much our core target audience.

>> and
>> defconfig needs special handling as a maximal sane configuration.  But I
>> personally don't see why you'd ever treat busybox on non-linux as
>> anything _other_ than something for experts.  (It's not like writing
>> toybox or Android's toolbox was all that _hard_.  If the macintosh
>> really needs its own busybox equvialent they can darn well write one.)
> 
> What do you propose to do?

I propose making allnoconfig useful again.

If you're going to support Linux targets, the best thing to do is
probably have a defconfig for each non-linux target that's the maximum
sane config for THAT platform.  (Otherwise you're going to be annotating
for newlib+libgloss in the config and it's a horrible can of worms.)  So
a defconfig.mac and a defconfig.netbsd and a defconfig.cygwin and a
defconfig.mingw and so on.  It gives people a starting point, and we can
even have a checkconfig that compares the config you made with the
target defconfig and warn you about symbols you've enabled that it
doesn't have, and if they do work please tell us so we can update that
target's defconfig.

If you really don't want to do that for some reason, the "selects"
suggestion is less painful than the current setup, it annotates Linux
dependencies without breaking allnoconfig.

A negative symbol would also avoid breaking allnoconfig at the expense
of further breaking allyesconfig, although that was given up for dead
years ago and was functionally replaced by defconfig so it's not really
a downside.

Rob


More information about the busybox mailing list