[ On Saturday, October 20, 2001 at 19:43:19 (-0700), Jason R Thorpe wrote: ]
> Subject: Re: stdio FILE extension
>
> Yes, we know what you're talking about.

Yes, _you_ might know what I've been talking about, but it's very
apparently clear that at least some of the other respondents have jumped
to completely incorrect conclusions either because they've not read what
I wrote, or they just didn't "get it".

> In any case, there is no real harm in continuing to do things the way
> we (that is, the people who act as system architects for the NetBSD
> Project) are currently dealing with the ABI versioning issue.

Indeed there's no short term harm in continuing to provide backwards ABI
compatability -- the only short term harm is to the credibility of those
who are raising what are apparently false objections to the mere option
of planning to bump the libc major number (for whatever reason!).

As for the long term, I suspect the only real harm can come from
unnecessary complexity contributing to errors, confusion, or
limitations.  Whether the level of complexity gets high enough to cause
harm will depend on how much future change to the API requires
maintenance of ABI compatability.  That harm would most likely take the
form of giving false expectations about the viability and accuracy of
that ABI compatability.

Oddly the kernel already contains simple options for enabling and
disabling support for binaries built on previous releases.  It's only
this shared library layer (and of course the source code for it) that
some people seem to have an unnatural fear of changing.  If the same
options were available for building shared libraries then maybe this
whole issue would quietly wither away (though that alone wouldn't solve
the version naming issue).

> And, if we were to select your way, there could be significant, annoying
> pitfalls at "major release" time

Can someone who thinks they know exactly what those pitfalls might be
please elaborate on them in enough detail to be convincing?

> (nevermind that just defining what exactly
> constitutes a "major enough" release is an issue that we haven't even touched
> on yet)

Of course not -- and unless users and developers alike explore the
relative risks and merits of _all_ of the options, it'll be impossible
to make such a definition too!

> for what amounts to zero tangible gain.

There seem to be several people who think there is something to gain.

One obvious issue is that the renames in use to maintain shlib ABI
backwards compatability are ugly and sometimes confusing cruft.  We do
many things on many levels to maintain compatibility with historical
interfaces.  The point here is that there's a relatively simple and
painless way to get rid of some of this cruft.

Indeed didn't you yourself post something suggesting that you had wanted
to get rid of some __RENAMEs in the aout->ELF transition?  Why would you
have wanted to do that if there was no tangible gain to be had from
doing it?

Personally I think the largest gain will be to the developers
themselves, with fallout that affects the overall quality of all the
code in the system as a whole.

> So, let's review:
> 
> 	"Our way"	No significant overhead, maintains full ABI
> 			compatibility with all previous NetBSD releases.
> 
> 	"Your way"	Chance of screwing over users[*] at upgrade time
> 			for basically no gain.
> 
> The choice is pretty obvious to me.

Since "my way" hasn't even been defined in any detail yet it's
impossible for you to evaluate it.  Indeed your attempt to claim that
there might be a chance of "screwing over users" suggests you too have
failed to read all of what I've written and to fully understand what
little I've proposed so far.  I have not ever suggested that users of
third-party dynamic linked binaries _must_ be left out to hang -- quite
to the contrary I've discussed the options they have and the options
that NetBSD can offer to alleviate their suffering.

> [*] We haven't even touched on the "no way to rebuild old app because
> vendor either doesn't exist any more, or source code for mission-critical
> app simply no longer exists".  I know of at least one NetBSD developer
> who was paid a good chunk of change to ensure this type of application could
> continue to run on an updated NetBSD system.

Actually we have touched on at least two possible ways to deal with
existing old binaries that cannot be rebuilt for whatever reason.  These
haven't been explored in depth yet, probably because there hasn't yet
actually been any convincing argument given for doing so.  The fact that
one "developer" has paid cash to ensure old binaries can still run is
simply evidence that the effort required to implement the chosen option
will likely be actively supported (assuming that developer continues to
hold the same priorities in the future, and of course continue to have
the means to offer such support too).

It might help though if names could be named and requirements could be
documented for analysis here....

> Anyway, I think it's safe to say that the current practice of doing
> symbol renaming for ABI versioning is not going to change, unless some
> better way of maintaining full ABI compatibility comes along.

I don't remember saying anything about changing or abandoning the
current practice of using symbol renaming to provide ABI compatability
-- only about adding a new step where the existing renames could be
eliminated at some point.  Obviously if changes that have required
renames in the past occur again in the future then more renames will be
needed for the duration of the next "major" release cycle.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>