From owner-freebsd-current  Mon Sep  6  6: 4:14 1999
Delivered-To: freebsd-current@freebsd.org
Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132])
	by hub.freebsd.org (Postfix) with ESMTP id DA12214E58
	for <current@FreeBSD.ORG>; Mon,  6 Sep 1999 06:04:07 -0700 (PDT)
	(envelope-from dufault@hda.hda.com)
Received: (from dufault@localhost)
	by hda.hda.com (8.8.5/8.8.5) id JAA07157;
	Mon, 6 Sep 1999 09:00:46 -0400 (EDT)
From: Peter Dufault <dufault@hda.com>
Message-Id: <199909061300.JAA07157@hda.hda.com>
Subject: Re: (P)review: sigset_t for more than 32 signals
In-Reply-To: <37D38367.C297FD64@scc.nl> from Marcel Moolenaar at "Sep 6, 99 11:03:35 am"
To: marcel@scc.nl (Marcel Moolenaar)
Date: Mon, 6 Sep 1999 09:00:44 -0400 (EDT)
Cc: current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL25 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> 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