Paulo Alexandre Pinto Pires wrote:
> What could be interisting, though, is that NetBSD could be not so 
> dependent on an specific kernel version to have things done right.  For 
> example, it would be very nice if one could boot an current kernel in a 
> release userland and not have bits like fsck, ps or ifconfig brake, and 

FWIW, bits like fsck, ifconfig and even ps don't break when you
have older userland then kernel.

> it would be even nicer if a user of a current system could boot his 
> stable kernel when he needed to do a crucial task, where stability is 
> essential.  This happens with Linux and is true to some extent in 
> FreeBSD.  And this would allow people to debug -current in even their 
> "production" machines at times when they're not at some really serious work.

Err, actually, NetBSD backward compatibility is very good, coutrary
to that of Linux or FreeBSD. On NetBSD, old binaries do continue to work,
if you include necessary COMPAT_* options to the kernel. Of course,
tools accessing kernel structures directly do need to be in sync
with kernel, so e.g. old vmstat/iostat/fstat don't work with new
kernel.

> I know nothing about POSIX threads, but it would be nice, if it doesn't 
> depend on too many opaque objects and types (that "expand" to underlying 
> real types and objects at compile time) in its standard API, to have the 
> ability to transparently switch from our native threads library to some 
> other at runtime (through e.g. LD_LIBRARY_PATH setting), so that one can 
> choose when he wants to debug and when he wants to be stable.  (Yet 
> nice, I am not saying this is or should be feasible.)

This is of course possible.  You don't have to use the system
pthread library if you prefer not to. You very likely cannot use
just different LD_LIBRARY_PATH, the app must be compiled with right
<pthread.h>

FWIW, LinuxThreads isn't particularily good pthread implementation.
It has number of issues, and is also quite slow, even for 1:1
threading implementation.  It works (IIRC FreeBSD offered it as an
option for system pthread library), but our libpthread is superiour
in many ways.

Linux POSIX Thread Library (NTPL) and the other Linux threading
project should be more decent. It may even be possible to port over
without too much efford, AFAIK it only needs LWP syscalls. I don't
know however if it's already considered stable tho - last I looked it
wasn't even in standard Linux kernel yet. Also, I'd prefer to avoid
Linux kwality software, and don't like LGPL.

Anyway, any efford is best spent by debugging our libpthread/SA.
It's already very decent, and will be one of best POSIX pthread
implementations available, once the remaining issues would be fixed.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.cz/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-