Subject: Re: SA/pthread syscall versioning
To: None <firstname.lastname@example.org>
From: Christos Zoulas <email@example.com>
Date: 12/11/2003 00:29:33
In article <163c01c3bf6f$3095e1f0$070414ac@pin>,
Christian Limpach <firstname.lastname@example.org> wrote:
>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.
Another issue is passing siginfo_t instead of ksiginfo_t in sa_upcall. We
could save the separate pool and the large copy from kernel to userland if
we do this, for the tradeoff in some loss of future compatibility, if ksiginfo_t
grows (which I don't think will happen). What do you think?