From owner-freebsd-current Mon Sep 6 9: 7:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id AA64C14ED3 for ; Mon, 6 Sep 1999 09:07:33 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id MAA03384; Mon, 6 Sep 1999 12:07:31 -0400 (EDT) (envelope-from wollman) Date: Mon, 6 Sep 1999 12:07:31 -0400 (EDT) From: Garrett Wollman Message-Id: <199909061607.MAA03384@khavrinen.lcs.mit.edu> To: Marcel Moolenaar Cc: current@FreeBSD.ORG Subject: (P)review: sigset_t for more than 32 signals In-Reply-To: <37D38367.C297FD64@scc.nl> References: <37D38367.C297FD64@scc.nl> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > kernel/userland - http://www.FreeBSD.org/~marcel/signal.diff There appear to be some fairly gratuitous name changes in here. 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. 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. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message