[FYI:  The following is my opinion and doesn't necessarily reflect the
NetBSD core group, or any other person for that matter.  This is something
that may need a higher level decision.]

On Sun, 15 Mar 1998, Brett Slager wrote:

: 	System calls whose interfaces have changed have been given new
: 	names to support libc "versioning."  Unfortunately, the old
: 	standard names are no longer exported via sys/syscall.h.
: 	This breaks some libraries and programs which rely on the syscall(2)
: 	interface to complete intercepted system calls.

Nothing should be relying on syscall(2).

With that in mind, pthreads is one of the very slim exceptions in that it
tries to fool the existing system into using its own changes.  Anything that
does try to fool the system and bypass libc _must_ break and _must_ be
updated to a new release so that they either:

- cover the old syscalls to take care of binaries which use the older
  function calls
- ensure that the package is _not_ compilable against the older system
  headers, which have differing syscall semantics, if the package does not
  cover the older function calls

Think about this:  fstat() is being called by 1.3-compiled programs as
__fstat13().  Not just as a syscall, but as the actual function entrypoint. 
Now let's say that SYS_fstat points to the new, 1.3, fstat with its changed
stat structure.  MIT pthreads will compile and export its faked function
fstat().  Oops!  That's the C entrypoint for fstat with the old structure,
but it's going to pass it to sys___fstat13() in the kernel.  What's more,
the new C entrypoint of __fstat13() isn't covered at all and will fall
through pthreads to libc. 

In the case of mit-pthreads, we really need to update libc to be thread
safe, and implement the reentrant counterpart functions.  Then, threads
could literally be dropped in with a minimal of code, with or without kernel
support.  (The kernel is in work, according to core.) 

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)