> >>Keeping such code out of the consolidation doesn't seem fair; Linux has
> > The gate is a shared resource; once something
> > is putback, we all agree to maintain and support it as a first class
> > citizen for as long as it remains. We are absolutely not going to go
> > down the Linux path
Keeping such code out of the consolidation doesn't seem fair; Linux has
The gate is a shared resource; once something
is putback, we all agree to maintain and support it as a first class
citizen for as long as it remains. We are absolutely not going to go
down the Linux path of incorporating ga
Keith M Wesolowski writes:
> It would be much better if this were done on a per-file or better yet
> per-package basis, so that distributions could, as they do today,
> elect to include or not include a particular feature. I don't think
> adding a lot of #ifdef SOLARIS is the right answer here -
Peter Memishian writes:
> projects are not necessarily aligned with Sun's business needs. Further,
> it was 32-bit SPARC kernel support in particular that I was thinking of as
> having potential "long-term impact" on Sun's resources.
... which is not an issue for me: trying to resurrect *that* w
Michael Shapiro writes:
> 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
> 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-I
On Tue, May 02, 2006 at 02:06:10PM -0500, Eric Lowe wrote:
> This brings up an interesting point, which is that we may have a lot of
> community supported, but non-Sun-supported, features some day, starting
> from this one (and with resurrecting the le driver which is related to
> this revival
>
> > 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
> 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
> outco
Stephen Hahn wrote:
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
Stephen Hahn writes:
> 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
The business reasons shouldn't be much of an issue for Open
* Rainer Orth <[EMAIL PROTECTED]> [2006-05-02 11:45]:
> Jonathan Adams writes:
>
> > > I know that, but I couldn't find any code dealing with the underlying
> > > issue
> > > in S9 sources so I have no idea how this was dealt with before (if at
> > > all).
> >
> > In Solaris 9, the SUNW,UltraSP
Jonathan Adams writes:
> > I know that, but I couldn't find any code dealing with the underlying issue
> > in S9 sources so I have no idea how this was dealt with before (if at all).
>
> In Solaris 9, the SUNW,UltraSPARC module was delivered. The bugid:
> > > 4944965 SUNW,UltraSPARC should not b
On Tue, May 02, 2006 at 08:28:17PM +0200, Rainer Orth wrote:
> Jonathan Adams writes:
>
> > > * When UltraSPARC I support is resurrected, it seems to be correct to
> > > rename /usr/include/sys/fm/cpu/UltraSPARC-II.h to UltraSPARC.h (or
> > > UltraSPARC-I.h) since this file already refers to b
Jonathan Adams writes:
> > * When UltraSPARC I support is resurrected, it seems to be correct to
> > rename /usr/include/sys/fm/cpu/UltraSPARC-II.h to UltraSPARC.h (or
> > UltraSPARC-I.h) since this file already refers to both CPU types.
>
> You should discuss this change with [EMAIL PROTECTE
On Tue, May 02, 2006 at 08:10:42PM +0200, Rainer Orth wrote:
> My sponsor request for
>
> 6414867 Revive UltraSPARC I support
> http://www.opensolaris.org/jive/thread.jspa?threadID=8028&tstart=0
>
> hasn't yet triggered any response, but since there are a couple of open
> questions, I
My sponsor request for
6414867 Revive UltraSPARC I support
http://www.opensolaris.org/jive/thread.jspa?threadID=8028&tstart=0
hasn't yet triggered any response, but since there are a couple of open
questions, I'd like to raise them here:
* Until US-I support was removed, you had
17 matches
Mail list logo
