sigsegv@rambler.ru wrote:

> Peter Eisch wrote:
>
>> It's been a while since the thread came around and I didn't chime in 
>> then,
>> but I have a few datapoints:
>
> I agree, there are some stability issues with NetBSD on sparc64, I 
> think they won't show that frequently if you primarily run it as a 
> router/firewall. I had numerous system hangs when building large 
> packages like mozilla, etc.  Unfortunately I don't have the expertise 
> to work on the kernel, not yet.  There are probably a handful of 
> NetBSD developers working on sparc64 port, compared to a large number 
> of Solaris or Linux developers.

You might be surprised.  It's my impression that All-64-Bit, All-The-Time
is *hard*.  Witness Solaris - you'd think that, by Solaris 9, with 3 OS
releases that are 64-bit under Sun's belt, that you could just build
everything as 64-bit and have it work, but that's still not even the case.

In the last few months I've seen my 64-bit Solaris "tcpdump" binary
croak ("yy_flex_alloc()" returning a value outside of the 64-bit
address space) and Berkeley DB 4.2.52 as well (svctcp_create() - a
Sun routine!  It's inside libnsl.so - also returning a value outside of
the 64-bit address space, because a stub RPC ".x" file provided in the
distribution was run through an "rpcgen" in 32-bit mode, not 64-bit).
So even with all this time to get things right, it's still clear that the
world is not 64-bit safe/clean yet ...

> I think it would be a tremendous help if more kernel hackers 
> contributed to NetBSD.  I know I will as soon as I learn kernel 
> programming.

If I had a ruble for how many times I've seen people post "as soon as I
learn ..." over the last 10 years, I'd be rich ;)

    - Greg