Rainer Orth wrote:
James Carlson writes:
Rainer Orth wrote:
>From my understanding, it was not. UltraSPARC I support was dropped when
32-bit SPARC was removed. The fact that US-I machines run perfectly fine
in 64-bit mode (and have been since Solaris 7) wasn't taken into
consideration. Yes, there was a small risk, but at least you had the
choice. With the wholesale removal, you didn't any longer.
There's more to it than that. Yes, dropping 32-bit kernel support was
an important issue, as keeping it would be a substantial burden to other
project teams (dtrace, for example, would need new hot patching
procedures for trace points for those few still using 32-bit mode
kernels). And not all US-I actually does work right with 64-bit mode
due to bugs, meaning some complexity in support.
But those bugs have existed since the introduction of 64-bit SPARC support
and seem to have hindered no one from running the machines in 64-bit mode.
AFAIK, no workarounds or whatever have been removed with the integration of
the US-I desupport case.
Sun never supported those machines in 64-bit mode. They always booted
by default to 32-bit mode, just because of the security bug.
More importantly, it would mean that project teams doing extensive
kernel work (such as the ones already named) would have to do testing on
old US-I machines, which at least at Sun are getting harder and harder
to find. They break down and can't be repaired due to a lack of parts.
They are expensive in terms of lab real estate, power, and heat.
They've long since fallen off the price list. They're very slow and
usually very limited in memory and disk space, and thus make poor test
machines. Many can't even boot the installer anymore.
Fully understood. That's the reason for my suggestion to allow for support
to live in ON that isn't tested any longer by Sun, but only by the
community.
Why does it have to be "in" ON?
When you add to that the fact that the marginal utility is extremely
small -- existing machines can reasonably run S9 or older and continue
doing so until the magic smoke escapes with little benefit from
OpenSolaris -- and that those still using US-I likely have little money
to spend on new hardware, the costs far exceed the value, which is (in
large measure) how such support decisions are made.
Existing machines can run S10 and SX:CE until today: you just need a couple
of symlinks (and previously need to rip out code in {inet, ufs}boot to
reject US-I machines).
I realize there's a hobbyist market out there for the ZX81's of the
workstation world, but it's not a place I'd expect any company to spend
its money.
That's one of the questions: what's to cost and who has to bear it. I can
understand the cost might increase massively if e.g. a new VM system would
require tons of special code to deal with those old machines, but if
there's no requirement for Sun to test and support US-I, the cost seems to
be far smaller.
Its still bigger than you think though. Carrying baggage around for
effectively dead hardware costs developers time --
* everytime you hg clone
* everytime you grep
* everytime you compile the tree
Additionally, the bits take up space on disks (think of the space
consumption multiplied across hundreds or thousands of workspaces --
though ZFS dedup will help with that now).
Additionally, the bits take up space on install media and customer systems.
Additionally, there is no way for consumers of the consolidation to
separate out those things that are "fully" supported, and those things
that are "caveat emptor" community supported.
-- Garrett
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
