Jon Buller wrote:

> I'm not sure I want to bring this up, but...
> 
> Do we want to:
> 1) Do the necessary work to make the PC532 work with /current again
> 2) Leave a note saying that you should do a cvs co -D <whenever>
>          if you want to get anything useful for it
> 3) Just leave it all as it is to further bit-rot
> 
> There was some talk about incorrect use of strncpy in the code base,
> and a simple grep turned up two uses in sbin/bim.  They should be easy
> enough to fix (if it's even considered a bug), but that left me with the
> thought that maybe we should just push it into /Attic instead so other 
> people won't be bothered with it (and other related pc532 stuff) in the 
> future if something like this comes up again.

Speaking of BIM, my pc532 just does this when booting:

    NS32000 ROM Debugger
    Version: Sat Jan 18 18:58:15 1992
    Auto-boot enabled.
    RAM free above 0x129c

    Command (? for help): 
    Auto boot in progress.
    Bad image number.

even though bim seems happy with the layout.

> Mine has been off for maybe 5 years now, I keep meaning to turn it back 
> on and put it to some use, but...
> 
> I like my fond memories of it, and don't want to see those die, but at 
> the same time, I don't want it to waste anybody elses time either.  I'm 
> (ever so slightly) worried that someone will get upset at all the time 
> they wasted in a code sweep fixing "dead" code and then go on to develop 
> a deep seated resentment towards anyone that may have caused that 
> problem for them.

I've been happy keeping at least the kernel building after sweeps.  I
suspect that having sys/arch/pc532 really adds very little work to
anyone doing a code sweep, and I'm also happy for people to skip the
pc532 directory and I can look after it next time I go to build a
kernel.

Not too long ago most of userland built statically, but anything using
pthreads didn't build because that requires ELF.  There were a handful
of other failures that I can't recall off-hand.  Every now and then I
need to build a new vmstat or ifconfig or something like that...

> I suspect we are facing the same issues with GCC, GDB, and other pieces 
> of code we need too.

GCC dropped support for ns32k in gcc4, so we lose big-time there.  The
other major issue is that we don't have ELF support nor shared libraries
with the current toolchain.  These are indeed reasonably big issues :-/

Perry Metzger wrote:

> I think we should decommission the port if it is not in working order
> by some given date -- I'd propose October 1. I don't like doing
> that, but if we can't have it fixed and working at some certain date
> in the future, clearly we aren't in a position to maintain this any more.

My last kernel is:

NetBSD 3.99.21 (PC532-virgin) #208: Sat Jun 17 00:32:56 EST 2006
        simonb@thoreau.thistledown.com.au:/var/tmp/KERNELS/PC532-virgin

I'd be curious to see when the last amigappc (to pick one example) built
and ran :-)

Cheers,
Simon.