There's a lot of confused terminology floating around; this is really
a topic for tech-smp.

Threading has very little to do with MP.  NetBSD has had "kernel
threads" for a while.  They're just processes which never leave the
kernel and don't have a user-space address space.   

> IN order to make use of any advantages that a dual processor SS10 might have 
> (I'll ignore the "ought to be" comment for now) you'd have to have a kernel 
> with true multi-threading capability and that isn't an issue when we talk
> about NetBSD, is it?

There is active work at the moment on SMP support for NetBSD.  

Anyhow, there are several work items involved here.  One is adding
machine-dependant support to deal with the mechanics of spinning up
multiple CPU's and routing interrupts to them; the other is changing
the machine-independant kernel scheduling and synchronization model to
deal with multiple CPU's.

There exists preliminary code right now for alpha, i386, sparc, and, I
think, vax, which will initialize and start up secondary CPU's to the
point of being able to run kernel printf() to the console, and then
leave them spinning with nothing to do.

As for the second part, UNIX kernel code is traditionaly
cooperativeley scheduled; user-space code may be preempted at any
time, while kernel code needs to yield the processor explicitly in
sleep() or tsleep().  splfoo()/splx() calls are used to lock out
classes of interrupts from certain regions of code.

This model breaks down when multiple CPU's are involved; locks need to
be introduced in order to protect critical regions, and, at that
point, once you have fine-grained-enough locking, you might as well
move to a preemptively scheduled kernel.

At this point, it looks like the folks actively working on SMP for
NetBSD are going to get there via a transitional "big lock" stage
(similar to what FreeBSD and Linux have been doing for a while),
before moving on to a more scalable, finer grained locking model and a
preemptively scheduled kernel on a subsystem by subsystem basis.

If I had to place bets, I'd guess that alpha will probably go MP-live
first, followed shortly by x86 and sparc.  The folks working on this
are all busy, so I can't predict when this will happen, and the more
you pester people about stuff like this, the longer it takes before
something actually emerges...

					- Bill