>
> > I am uncertain that a sponsor will successfully manage to integrate
> > this fix. The decision to drop US-I support was made for a complex of
> > reasons, some business, some legal, and has had various follow-on
> > effects (like elimination from test farms, among others). One
> > outcome, perhaps undesirable, you may be constructing the first
> > long-lived patchset, which is itself an interesting discussion.
>
> Can't the same be said for the PPC port?
>
> I agree this is a very interesting case -- and it may set some very
> important precedents for community projects that are not necessarily
> aligned with Sun's business needs -- especially when those projects
> stand to have significant (and perhaps long-term) impact on Sun's
> own resources (e.g., testing).
I agree this should be discussed in terms of its long-term precedent and
guiding principles for future porting and EOL issues. That said, I wouldn't
confuse a full-fledged port with a CPU variant: PPC is new *ISA*, whereas
US-I is a tiny variant from another CPU we still support, US-II, and has
the same ISA. So you have a whole raft of issues that don't come up here, e.g.
- disassembler support
- DTrace ISA support
- linker ISA support
- librtld_db ISA support
- procfs ISA support
- mdb ISA support
- and the like ...
There are two technical issues with US-I:
1. The pink zone fix, which extends its hooks way beyond the US-I CPU module.
To avoid lawyers rounding me up, I'll quote from the Solaris 7 boot.conf:
# On systems containing 200MHz or lower UltraSPARC-I processors,
# it is possible for a user to run a 64-bit program designed to exploit a
# problem that could cause the processor to stall. Since 64-bit programs
# cannot run on the 32-bit kernel, the 32-bit kernel is chosen as the
# default boot file on these systems.
2. The fact that, in part due to (1), we EOL'd the 32-bit kernel on SPARC
once US-I was EOL'd. We definitely do not want to bring back 32-bit
sun4u kernels: that has a massive developer impact on the gate.
So one way to make this issue a bit more approachable is to think about
bringing back a 64-bit only US-I with the boot.conf caveat effectively built-in
and to see if that change could be very much limited to a small set of changes
to spitfire.c. I'm not necessarily casting my vote "yes" yet, but this is a
way to at least look at the scope of this particular change without feeling
like we have to have the entire ISA port discussion or bring back (1) and (2).
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
