Garrett Wollman wrote:
>
> <<On Mon, 06 Sep 1999 11:03:35 +0200, Marcel Moolenaar <[EMAIL PROTECTED]> said:
>
> > kernel/userland - http://www.FreeBSD.org/~marcel/signal.diff
>
> There appear to be some fairly gratuitous name changes in here.
Elaborate, please.
> Also, my own feeling is that it would be better to continue to use
> integral types for signal sets inside the kernel. This makes the code
> much easier to follow (at least for me), and underlines the necessity
> of compatibility interfaces if the size is ever changed again.
Having an integral sigset_t, if at all possible, has the disadvantage that
existing expressions on the new datatype are probably valid syntactically
speaking, but may not be semantically valid, which makes debugging rather
painful. Having a struct ensures that the compiler will barf.
I just doubled the number of signals in a sigset_t, because it was planned
that way (compatibility with NetBSD and such). The latest working version
has thus 128 bits in a sigset_t. (BTW: That was before you asked me if I
could hold off).
> As for the setjmp/longjmp problems I mentioned... I wonder if it might
> not be preferable to make them system calls as well. There are some
> hints in the siglongjmp source code to suggest that the restoration of
> context needs to be atomic with respect to signal masking and
> delivery. That would make it possible to introduce versioning in
> JMP_BUF structs, which would in turn make it easier to deal with
> backwards compatibility in the future.
The setjump/longjump family of functions are userland function AFAICT. For
that reason I would not choose to add syscalls. If atomicy is a real
problem, then it may be preferable to have the kernel help out. Anyway,
this issue is basicly independent of the sigset_t change.
--
Marcel Moolenaar mailto:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD project mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
