standalone applets

Bernhard Fischer rep.nop at aon.at
Mon Jan 16 09:22:49 UTC 2006


On Sun, Jan 15, 2006 at 07:11:57PM -0600, Rob Landley wrote:
>On Sunday 15 January 2006 14:32, Bernhard Fischer wrote:
>> On Sun, Jan 15, 2006 at 03:54:05PM +0100, Bernhard Fischer wrote:
>> >On Sun, Jan 15, 2006 at 12:39:32PM +0100, Bernhard Fischer wrote:
>> >>On Fri, Jan 13, 2006 at 11:56:20PM -0600, Rob Landley wrote:
>> >>>Are you doing anything with the standalone stuff, or should I brush that
>> >>> off and try to nail it on myself?
>> >>
>> >>For now i won't look at it, so please go ahead.
>>
>> Short brainstorming for standalone.
>>
>> 1) config
>> Teach the config system to accept 'M' (make all base applets tristate)
>
>The thought of this gives me _hives_, but I agree it makes a certain amount of 
>sense...

I wonder why tristate is currently rejected. I looked at unblocking
tristate in the config thingy some time ago, but all i remember was
horrors.
>
>> 2) Makefile/Rules
>> 2a) Add all applets marked with 'M' to the build-standalone list.
>>     STANDALONE_CFLAGS:=-Wl,--entry=$(APPLET)_main \
>>        -Dbb_applet_name=$(APPLET)
>
>Ok.  Um...
>
>Interesting way to go about it, but sure.  (You're sure uClibc isn't going to 
>blow chunks or something?  I've seen a number of weird things with the crt0 
>and such that make me nervous about expecting that to "just work"...)

I didn't try this with uClibc, but only with glibc where it does work
as expected.  If it doesn't work, it's clearly a bug in uClibc.

>> 2b) provide bb_show_usage() per applet
>>     Either in the applet itself or by e.g. compiling usage.h into an
>>     $(APPLET)_show_usage.o
>>
>> Sounds ok?
>
>I'm trying to remember how I attacked that earlier.  I remember making it work 
>at one point, but not what I actually did...
>
>> >1) If CONFIG_FEATURE_SHARED_BUSYBOX is set, I propose to build
>> >libbusybox with -Wl,z,nodelete. What do you think?
>
>What does nodelete do?
>
>Firing up "man ld", -z nodelete "Marks the object shouldn???t be unloaded at 
>runtime" which not only means nothing to me but isn't actually quite 
>english...
>
>I _suspect_ what you're trying to do is force the runtime loader to cache the 
>library so it stays in memory between invocations, and I'm really not sure 
>that's a good idea.  If they're using busybox their shell or for init, it'll 
>stay in memory.  If not, it's no worse than doing a repeated exec of anything 
>else, and the normal OS mechanisms for not behaving stupidly should apply.  
>We don't have to say "Oh, we're _special_", do we?

The only OS mechanism which would apply there would be to eventually
keep the .so in the buffer-cache, afaics. So let's assume that
people who really want to keep the .so resident know what to do. Besides
that, from the looks uClibc doesn't implement nodelete ATM.

>> >3) "make install" needs an option to select whether the headers should
>> >be installed or not. Personally i'd rename libbb.h to libbusybox.h,
>> >but that's purely cosmetic and i guess Rob doesn't like it.
>
>I don't feel strongly either way.  I suspect if we're installing a header it 
>should probably be called "busybox.h", but my /usr/include already has 
>"libgen.h", "libintl.h", "libio.h", "libtcc.h", "aalib.h", "zlib.h", and of 
>course "stdlib.h".  Looks like "libbb.h" would fit right in, if you ask me...
>
>However, installing a header implies that people are likely to use libbb 
>outside of busybox.  While I agree this is a definite possibility, I'm not 
>sure how much we want to encourage it.  What we want to avoid at all costs is 
>worrying about external compatability with third party software bound to our 
>API.  New releases of busybox (even minor dot releases) can break apps 
>depending on an libbb.so.
>
>We haven't yet had the cost-benefit analysis discussion on this yet.  The make 
>standalone thing is something people have asked for repeatedly over the years 
>(it's just what they're familiar with), and if you're going to do that then 
>libbb.so makes sense from a size perspective.  But the downside of libbb.so 
>is compatability issues, if you try to mix and match applets linked against 
>different versions of libbb.so it's either going to hurt or the big cleanup 
>we want to do to libbb some day isn't possible.  And if third parties start 
>using libbb.so and we cavalierly break them with every dot release, that's 
>going to suck.  But it's _our_ library, we have the right to break it if we 
>clean up in-tree users, and we are _not_ exporting a stable API from the 
>thing right now.
>
>(Another thing we should be clear about is that busybox is gpl, not lgpl, and 
>a library derived from it is thus gpl not lgpl.  It's a packaging convenience 
>for us, not a different license.)

You're right. Let's not install the headers for now.

Thanks for your comments!



More information about the busybox mailing list