From: "Christos Zoulas" <christos@zoulas.com>
> 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?

Yes, that would be good.  Actually, there is no compatibility issue because
in pthread__upcall, the arg pointer is a pointer to the siginfo_t on the
stack and a larger struct _ksiginfo would still work with an old library.
It would be good though (since in libpthread we use siginfo_t) to leave
enough space on the stack to fit a complete siginfo_t and then only copy out
the currently used part (i.e. struct _ksiginfo).  This would also fix the
problem that right now we leak unused kernel memory to userspace, because we
don't clear the padding part of siginfo_t (Yamamoto Takashi mentioned this
to me in private email).

    christian