[geeks] Can someone sell me a cheap ultra sparc :-)

[Scott Howard]

On Sat, May 31, 2003 at 11:38:14AM -0400, Charles Shannon Hendrix wrote:
> On Sat, May 31, 2003 at 11:14:17PM +1000, Scott Howard wrote:
> 
> > The primary impact of these changes are to systems that rely on third-party
> > 32-bit kernel modules: firewalls, kernel-resident drivers, and replacement
> > filesystems, for example. These systems must be updated to use 64-bit
> > versions of those modules.
> 
> I don't see why they would do this.
> 
> 32-bit programs are all you need sometimes.  Some sites won't need
> 64-bits for years to come.
> 
> Is it that much maintenance work for them?

Unfortunately, it is.  Having to maintain 2 copies of the kernel, all
kernel modules, many user-land apps, not to mention diagnosis/analysis
tools, etc, just to support machines which will be at least 6 years old
at the time Sol10 is released doesn't really make much sense.

Of course, going full 64-bit doesn't mean that you can't still run 32 bit
programs - it just means that the kernel and the like have to be 64 bit,
32 bit userland apps will still work perfectly.

> > Another impact of these changes is that UltraSPARC systems that contain
> > UltraSPARC I processors with clocks that run at 200MHz or lower frequencies
> > might not be supported in a future release. 
> 
> This sounds awfully arbitrary.  Is Solaris going to check your clock
> speed and shut off if its too low?

That's exactly what it does today (checks the CPU type, and defaults to
the 32 bit kernel if it's "too low", unless you tell it otherwise).

As I said before the current builds of Solaris 10 actually don't do this,
it just defaults to 64 bit mode even on these Ultra-1's. Given that they
will be beyond EOSL (End Of Support Life) by the time Sol10 is released I
suspect this is how it will stay - and if you're worried about the possible
"CPU-stall" code the simple solution will be to upgrade to something which
is supported.

  Scott
  (Speaking for me, not Sun).