[ On Wednesday, October 17, 2001 at 17:34:20 (+1000), Simon Burge wrote: ]
> Subject: Re: stdio FILE extension 
>
> Greg A. Woods wrote:
> > 
> > Oh, but it does -- the reason for the magic renames and such is so that
> > the kernel ABI can change without changing the libc ABI.  How much more
> > related can you get?
> > 
> > If the kernel wants to simultaneously support a prior ABI variation then
> > the obvious way to do that is with the /emul feature.
> 
> For chrissakes could you _please_ look before sprouting off about the
> reasons for why we do symbol renaming?  ~Half the symbol renames we have
> are _not_ for kernel ABI changes.

Oh my goodness -- I see I should have been more pedantic in my choice of
words and said something more along the lines of "the _primary_ reason"....

but this isn't really about the magic renames -- they're just one of the
most obvious things that gets cruftier over time....

> I _like_ the fact that I don't need to recompile _every_ third party
> application each time I upgrade from release to release.

Well, depending on what you mean specifically by "release" I will either
agree, or not agree.....

I too realy like that ability, but only to a point, and beyond that
point I _really_ dislike it.

>  I like that I can grab a binary from an old box and
> run it on a new box.

I doubt I would _ever_ do that in a production environment (where that
means any environment where software development and testing is rarely,
if ever, done) -- even if it worked and even if there were no observable
differences in the result, and even if it saved me a whole lot of time.

Even so there are several ways that can be made to work....

>  I like that I can try out a new kernel for a while
> (with some little lossage from some of the kernel grovellers) before I
> decide if I want to keep it.

Ah, well, of course -- but here I think you're talking about minor
"releases", not "major" releases (and if you are you're far more brave
than I am at booting test kernels on systems with radically different
userland builds).

> The reasons for not changing have been described a couple of times now.

The reasons described so far for not incrementing the shared libc major
number at some well defined points in the future have no apparent basis
in the facts as they relate specifically to NetBSD.  There's been lots
of whining and moaning about the difficulties that were encountered the
last time around (which IIRC was done without good planning and which
should serve as a learning tool, not an excuse for future avoidance);
and lots of speculation about third party products (but so far only one
such product has beeen mentioned and it specifically is a very bad
example since it's vendor seems very willing to keep up with new NetBSD
releases!).

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