Date: Mon, 6 Sep 1999 09:43:19 -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: <199909061343.JAA07224@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... I thought about this a bit more and thought of a good two-step process: 1. Immediately do roughly what you displayed only without increasing the number of signals but instead using two sixteen bit ints, and commit after testing. This will be binary compatible with the existing syscalls and will start to compile-time break two classes of programs: Those using sigset_t access methods against non-sigset_t's; Those directly accessing sigset_t's. Programs doing both of these, i.e. directly manipulating unsigned longs on the i386, will not be detected but will continue to work as they do now. 2. Switch to the higher number of signals using the approach I suggested making the high 16 bits of the "header" word an unusual pattern of mask bits by looking at bits unlikely to ever be masked. This pattern is architecture dependent, but it doesn't matter much as long as the pattern is for the most widely used system, i.e., i386. By encoding the number of ints that follow in the array in the low order 16 bits you'll be limitted to 2,097,152+1 signals with this approach, but that won't be a restriction for a while. Now you can detect in the kernel calls likely to be from the final class of broken programs. 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?199909061343.JAA07224>