From owner-freebsd-hackers Thu Jun 27 05:43:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA22181 for hackers-outgoing; Thu, 27 Jun 1996 05:43:43 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA22171 for ; Thu, 27 Jun 1996 05:43:38 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id WAA10241; Thu, 27 Jun 1996 22:40:19 +1000 Date: Thu, 27 Jun 1996 22:40:19 +1000 From: Bruce Evans Message-Id: <199606271240.WAA10241@godzilla.zeta.org.au> To: hackers@freebsd.com, jau@jau.csc.fi Subject: Re: POSIX.4 signals + other POSIX.4 stuff to FreeBSD... Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > the kernel though. The kernel seems still to be infested with > fragments of code that assume sigset_t is a simple integer > type ANDing and ORing bits in the sigset_t variables instead > of using the POSIX.1 macros to manipulate the signal sets. The kernel is allowed to do this as an optimization since it knows that sigset_t is an unsigned int in the "machine-independent" file . The POSIX macros require the sigset_t to be indirect so they are likely to be unnecessarily inefficient. > containing such an array. I have now more or less figured out > all these code fragments within the kernel itself, but it seems > that also the Linux application binary interface etc. LKMs have More importantly, the size of a sigset_t is appart of the BSD binary interface. The kernel would have to support variably-sized sigset_t's to support old binaries :-(. There is no such thing as a variably-sized struct, and the current sigset_t doesn't encode its size, this isn't easy. Bruce