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