From owner-freebsd-current Mon Sep 6 10:36:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from gaia.euronet.nl (gaia.euronet.nl [194.134.0.10]) by hub.freebsd.org (Postfix) with ESMTP id 054A21592D for ; Mon, 6 Sep 1999 10:35:57 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from scones.sup.scc.nl (i138.ztm.euronet.nl [194.134.112.99]) by gaia.euronet.nl (8.8.8/8.8.8) with ESMTP id TAA23894; Mon, 6 Sep 1999 19:34:10 +0200 (MET DST) Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id TAA35934; Mon, 6 Sep 1999 19:34:07 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <37D3FB0E.94662026@scc.nl> Date: Mon, 06 Sep 1999 19:34:06 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: (P)review: sigset_t for more than 32 signals References: <37D38367.C297FD64@scc.nl> <199909061607.MAA03384@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garrett Wollman wrote: > > < 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:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message