standalone applets

[Rob Landley]

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...

> 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"...)

> 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?

> >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.)

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.