On Tue, 27 Aug 2002, M L Riechers wrote:

> So that's it.  I was really, really impressed to discover this.  I
> submit that potentially many newbies to NetBSD may be similarly
> impressed.

Yes, it was nice.

> Now wending to the negative, the performance issues associated with
> making these oft-used programs in /bin and /sbin dynamically loaded
> worry me.

Yes. However ironically this step may well be the one that makes dynamic
linking get a speed boost. :-)

> And parenthetically, the notion of adding a /rescue thingy made me go
> "whoa!!!" To me, /rescue seems to be a combination of reaction to
> change of long-standing structure, a visceral reaction to the word
> itself (rescue? Is this NetBSD thing dangerous?), and what seems to be
> a blatant program redundancy.  But, except that others might react the
> same way, I'm really not sure that my adverse reaction should be
> counted for very much.  (I not on the list where this was originally
> discussed, so this hit me cold.)

If a name other than /rescue works better, we'll do it. The idea though is
to keep around the tools you need to be able to recover in case you do
have a problem with dynamic libraries.

> On the other hand, I've heard some good arguments from people I've
> come to respect in favor of the notion.  In particular, I'm impressed
> by the language argument.  But frankly some of the other arguments
> went over my head.  Might'n someone with a handle on this give a poor
> bit-twiddler an "executive overview" on the goodies you're trying to
> achieve?
>
> So, I'm dreaming of a compromise position.  Isn't a -static'ally
> linked program really just a rigorously degenerate case of a
> -dynamic'ally linked one?  And, isn't every -dynamic'ally linked
> program simply a trade-off between how many instructions are included
> in the program, and how many are "shipped" off to load-time library
> land? At one extreme, we could have a program that merely called a
> library routine, then exited, and at the other, does entirely
> everything within itself, having no need to call a load-time
> library. (Whether the necessary support comes from linked modules --
> I'm trying to stay away from the term static library, which is a
> distracter -- or from freshly written programming is irrelevant.)

No, there are also symbol visability issues too.

> If this is correct, then, it seems to me, we change the concept of
> -static and -dynamic to simply throw out the concept of -static: _all_
> programs are -dynamic, it's just that some are "less -dynamic" than
> others, to the degenerate case. From there, the trick is 1: to "load
> up" /bin and /sbin programs with enough support routines that they
> require an "optimal" level of assistance from load-time library
> routines -- with "optimal" tending toward "minimal" with an eye toward
> performance and robustness.  And 2: change whatever dynamic load
> processes are in place to ensure that /bin and /sbin programs (and
> potentially all programs) to "fall back" to a degraded mode of
> operation if the desired load-time library or support is missing.

The problem I see with this is that the programmers are loading libraries,
whereas you're more describing loading modules. The difference being
programmer consciousness levels. If you have to be able to live without
them, then they aren't a library. :-)

Also, as I said before, we thought about this. And folks who understand
binutils and gcc better than I thought HARD about it. And found it to be
unworkable. Yes, we could start doing the things you describe, but we will
run into problems that are more of a mess than making /{s,}bin dynamic.

Take care,

Bill