Date: Mon, 6 Sep 1999 09:00:44 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: marcel@scc.nl (Marcel Moolenaar) Cc: current@FreeBSD.ORG Subject: Re: (P)review: sigset_t for more than 32 signals Message-ID: <199909061300.JAA07157@hda.hda.com> In-Reply-To: <37D38367.C297FD64@scc.nl> from Marcel Moolenaar at "Sep 6, 99 11:03:35 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> Description: > When we want to support Linux binaries in the future and possibly also want > real-time signals, then we need to support more than 32 signals. > > Current status: > The diffs result in a working backwards compatible GENERIC kernel. The > linuxulator also doesn't seem to be broken. Recompiling programs (such as > sh) also seems to work *in general*. > > Known problems: > Building world fails because the freshly built cpp segfaults. A setjmp call > that may be involved matches the problem of a return address being 0. gdb > does not display a complete backtrace... > > Diffs: > kernel/userland - http://www.FreeBSD.org/~marcel/signal.diff > linux module - http://www.FreeBSD.org/~marcel/linux.diff > > To do: > o LINT needs to be compiled to make sure most code has been changed, > o most of userland still needs be touched, > o the alpha port needs to be taken care of. > > Your suggestions, comments, criticism and participation is requested! This is convenient, I had just been discussing this with someone. Firstly, you should get rid of any explicit 32, 31, etc and anything else tied to the assumed number of bits in an int. Secondly, I'd personally make it scale to a ridiculous number of signals such as 4096 by changing a single manifest constant to really thrash things out. Finally, an extract from some earlier thoughts about expanding explicitly to 64 signals: ... If we go with the moral equivalent of this struct (not really, see below): typedef struct { unsigned int n; uint64_t v; } sigset_t; where "n" is the number of signals it will be easy to catch broken programs using improperly initialized sigset_t's (only valid value for "n" 64), and we'll be ready in case once people start using pools of unnamed signals they want many. To get around the issues (ordering i.e. n must be first in memory so you can see how many signals in this implementation, new versions of the compiler change alignment for uint64_t, etc), I'd make it an array of three uint32_t. With machine specific sigset_t access macros you could get back to manipulations of long longs. Or let it be three native unsigned ints (some typedef unaffected by compiler switches), put the array size in v[0], and let the size of the array and the size of the int determine the value of NSIG or vice-verse. I would take an approach that will detect many broken programs, probably the array of three native ints. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909061300.JAA07157>