[ On Friday, October 19, 2001 at 12:40:01 (-0700), Jason R Thorpe wrote: ]
> Subject: Re: stdio FILE extension
>
> SunOS 4 -> 5 was effectively changing to an entirely different
> operating system.

Well, sort of -- though in many ways much of what changed
w.r.t. programming interfaces was only in a shift of what was considered
"standard" vs. what was considered optional.  Sure lots of user-land
stuff moved around too, but again that was more standard vs. optional
swaps too.  Of course there was also a.out to ELF in that transition
too.

> SunOS 5.8 -> 5.9, as I understand it, will be going from ILP32 -> LP64
> userland.

yes, and IIRC there are some other rather tricky ABI changes too....

> These are both pretty big deals.

Yes, that was my point -- they were "major" releases (regardless of how
the marketing numbering plans changed or did not change).

In those transitions you were pretty much forced to recompile everything
and the ABI for dynamically linked programs changed.

It wouldn't have been such a big deal though except for the fact that
most serious users were also using third-party binary-only applications
and so they had to co-ordinate their upgrades with availabitlity of new
software releases from their third-party vendors, and with their ability
to migrate to the new third-party software releases.

This is not (yet) the case for the majority of serious NetBSD users.
Most serious (i.e. important) NetBSD users either compile their own
software already, or they effectively get it all from the same source
they get NetBSD itself from (eg. pkg binaries in the release CD sets).

> How is this like changing from NetBSD 1.x -> NetBSD 2.x, considering
> that:
> 
> 	(a) The operating system will still be the same -- the most
> 	    that will really be changing is the *kernel*.

That doesn't really mean anything -- unless what you mean by "the
operating system" is the API; and if so then it's not so much that it
won't really change, but that it won't shift sideways and leave a gap
that takes application developers by surprise.

> 	(b) The binary formats are staying the same.  (Hell, even the
> 	    "1.4 a.out" -> "1.5 ELF" transition went pretty smoothly,
> 	    and that was a minor relase!).

ah, yes, but "binary format" != ABI, at least not generally speaking
since in theory one can convert from one 

Sure the 1.x to 2.x ABI _could_ remain the same, but when there are so
many reasons to want to change it why not do so?

In my experience the a.out -> ELF transition was a very major upgrade,
even with /emul to assist early adopters.  I think it should have been
called NetBSD-2.1, but of course with not all ports changing at the same
time there's a little bit of a marketing conflict between the naming of
the source base release and the per-platform binary releases.

Given the history of NetBSD release management though I'd have been even
happier if all 1.x -> 1.(x+1) were instead X.1 to (X+1).1, i.e. clearly
demarked as "major" releases.....  But that's neither here nor there --
it's all just a matter of perspective and expectation management.

Certainly with any "major" release of any operating system there's an
expectation amongst users that they should upgrade their application
binaries anyway, regardless of whether it's really absolutely 100%
necessary or not.  From the average user's perspective a "major" release
upgrade is in many ways like transitioning to a whole new hardware
platform too, except of course they don't actually have to change any
hardware if they don't want to.

> So, some of us considered ditching the __RENAME'd symbols during that
> bump.  But the problem is that not everyone could switch at the same
> time, therefore it was deemed inappropriate.
> 
> "That ship has sailed, buddy!"

but it didn't sink on its maiden voyage.  it's still sitting safe in its
berth and it will be ready to sail again someday.  if we all plan
carefully for that day then it won't sink on its next voyage either.

Now if NetBSD were trying to comply with some outside ABI that would be
one thing -- but so far as I can see NetBSD isn't even trying to
maintain native ABI compatability with any other *BSD.

Of course even ABI specifications go through major releases too, and
most of the one's I've seen do that have only ever managed the most
minimal backwards compatability through such transitions.  Change is not
a bad thing when it's reasonably managed, especially not if it's for the
better!  :-)

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