I believe we do have the manpower and more importantly, the talent. The
flexibility 
you mentioned does lend itself to other things as well, including thread
migration. 
Cluster computing becomes a lot more realistic, as well.

	----------
	From:  Guenther Grau [SMTP:Guenther.Grau@bk.bosch.de]
	Sent:  Friday, September 18, 1998 3:39 PM
	To:  tech-kern@netbsd.org
	Subject:  Re: Floating point in the kernel

	John F. Woods wrote:
	> But I hope that threads (user threads, anyway) will not be made
*too*
	> lightweight:  if the kernel is aware of user threads and schedules
them
	> (as opposed to threads existing as figments of user processes'
imaginations),

	But please don't make it as complex, configurable, flexible and
	complicated
	as the solaris threads. I don't think that we have the manpower to
	properly design and implement this, and IMHO it is overkill to have
	kernel threads, which are mapped to one or many process threads, and
	which
	are bound or not bound to a certain cpu. Flexibility is great, but
not
	when it get so complicated :-)

	> then (a) you get non-blocking I/O for "free" (one thread blocking
in I/O
	> doesn't block other threads in that process), and (b) different
threads of
	> a process can make use of multiple CPUs (OK, so that's more
interesting on
	> a 256 processor KSR machine than in is on a dual-Pentium... ;-) ).
That

	I think even on a dual cpu machine, cpu-intensive tasks will
definitely 
	run quicker if split up in independend tasks.
	Now, if we only had SMP and kernel threads already in the tree, the
	(NetBSD-) world would be a better place :-)

	  Guenther