Subject: Re: SA/pthread syscall versioning
To: Allen Briggs <email@example.com>
From: Christian Limpach <firstname.lastname@example.org>
Date: 12/10/2003 23:44:34
From: "Matt Thomas" <email@example.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
> 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
> 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.
* 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
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.