From: "Matt Thomas" <matt@3am-software.com>
> I agree versioning is needed.  I'm just wondering about its future
> implications.  Once 2.0 is released, its SA syscall interface will need to
be
> supported by future COMPAT_xxx code if the SA syscall interface is ever
> incompatibly modified or enhanced.

Ok, that's reasonable...  We'll deal with the (un)maintainability of the
compatibility code once we have to...  The version number should help and I
don't need to version sa_register to add the version number since we're
still pre-2.0.

> Maybe some care should taken now to make sure the new SA syscall interface
> will not need such a future flag day.
>
> Also, I'd like to see a description comparing the current SA syscall
> interface to the new improved one.  There may be ways of supporting
> the old programs that aren't much work.  Anyways, those syscalls
> should be documented.

- sa_unblockyield:
* removed
- sa_register:
* add version number
* add argument stackinfo_offset (=ss_sp-pthread_t+struct stackinfo).  struct
stackinfo allows to return an upcall stack to the kernel without making a
sa_stacks syscall (save 1 syscall on each upcall).

With sa_unblockyield gone, the interface should be more stable again, except
for things like adding stackinfo_offset for which we can reasonably have
compatibility code.

One other change for which it would be a nightmare to maintain compatibility
code is a change in the signature of the upcall function.  There's a few
(possible) changes which might need that:
- returning unblocked events on any upcall
- returning multiple siginfo structures with a single upcall

Other than that, I cannot predict the future and please also keep in mind,
that not every incompatible change requires a change in syscall signatures.
We had such a change on 2003/11/17 and the changes between rev's 1.44 and
1.45 of sys/kern/kern_sa.c are a good indication why it would be impractical
to maintain compatibility for certain changes.

    christian