In article <163c01c3bf6f$3095e1f0$070414ac@pin>,
Christian Limpach <chris@pin.lu> 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?

christos