Subject: Re: UltraSPARC-T1 docs
To: Brett Lymn <blymn@baesystems.com.au>
From: Timo Schoeler <timo.schoeler@riscworks.net>
List: port-sparc
Date: 02/27/2006 08:55:16
thus Brett Lymn spake:
> On Sun, Feb 26, 2006 at 04:23:33PM +0100, Timo Schoeler wrote:
>> the main problem (as pointed out at misc@openbsd.org btw) is that 
>> documentation of the CPU itself, but not about the glue logic 
>> surrounding it, is (usually) not sufficient.
>>
> 
> The only problem being that when someone pointed out that it was _not_
> just the processor documentation then they were promptly flamed and
> told to got write the code themselves.  It looks like the
> documentation for the hypervisor API is there which should be enough
> to get things going.  Even if it is not:
> 
> <http://cvs.opensolaris.org/source/xref/on/usr/src/uts/sun4v/>
> 
> may help out with some clues.  So, there is a lot more information out
> there than you may have been lead to believe.

maybe, maybe not. either way, i'm sorry to have said that Sun began to 
or does suck in way of propagating 'openness' in contrast to the 
openness they provide.

what makes me thinking a bit is that neither SMP for sparc64 works (due 
to whatever, last update was 'lack of time' of the developers), neither 
US III and successors are supported (which was cleanly pointed out to be 
a lack documentation), neither a simple X2100 runs fully supported 
(okay, that's nVidias fault).

so maybe there are differences in what one calls a machine 'supported'. 
maybe the OpenBSD guys think in a more 'complete' way (and surely they 
start to flame as soon as there's the possibility to do so ;)...

> Having said that, one wonders why the hell anyone would want to run a
> single threaded, big lock style kernel on hardware that is designed to
> run highly multi-threaded software.  Performance will suck, Sun will
> tell you this.

sure.

timo