Peter,
> Thanks for submitting the request to revive the UltraSPARC I
> support. Rather than integrating this into the ON consolidation
> due to engineering constraints (see below), the best way forward
> is for this support to be maintained either by yourself
> and/or an interested team of OpenSolaris folks as an OpenSolaris
> project. This would be hosted on the www.opensolaris.org website.
> Have a read of http://www.opensolaris.org/os/communities/ as a
> starting point for this; posting to the
> opensolaris-discuss at opensolaris.org
> would be the point to start the ball rolling for the project.
I'd consider this only as the solution of last resort, if the sponsor
request is really and finally rejected, which, I suppose, would have to be
done by the responsible ARC committee.
> Supporting old hardware from an engineering perspective is non
> trivial. The reasons being that the older hardware may not actually
> support the newer facilities within ON, for example the FMA
> framework and dtrace or they may support it in some limited fashion
> and thus cause exceptions within the code base. Having the older
> hardware would increase the test matrix and as such increase the
> time it takes for the tests to complete. Maintaining that many
> old machines/systems may also prove to be unreasonable (thinking
> about hardware failures here).
As you can see from the webrev I posted during the discussion on
opensolaris-code, none of this is currently the case for the 64-bit
UltraSPARC I revival: the code changes are completely trivial. By your
argument, support for UltraSPARC II would have to be removed as well, since
there's no FMA support for both CPU types (and, if I understand Mike
Shapiro's post on fm-discuss some time ago correctly, the actual changes
for FMA support on US-I and US-II would be quite similar).
Regards.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
