From owner-freebsd-hackers Wed Jun 26 12:38:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA00490 for hackers-outgoing; Wed, 26 Jun 1996 12:38:31 -0700 (PDT) Received: from jau.csc.fi (jau.csc.fi [193.166.1.196]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA00459 for ; Wed, 26 Jun 1996 12:38:17 -0700 (PDT) Received: (from jau@localhost) by jau.csc.fi (8.7.5/8.6.12+CSC-2.1) id WAA19711 for hackers@freebsd.com; Wed, 26 Jun 1996 22:35:52 +0300 (EET DST) From: Jukka Ukkonen Message-Id: <199606261935.WAA19711@jau.csc.fi> Subject: POSIX.4 signals + other POSIX.4 stuff to FreeBSD... To: hackers@freebsd.com Date: Wed, 26 Jun 1996 22:35:51 +0300 (EET DST) Reply-To: jau@aphrodite.funet.fi Latin-Date: Miercuri XXVI Iunie a.d. MCMXCVI Organization: Private person Phone: +358-0-6215280 (home) Content-Conversion: prohibited X-Mailer: ELM [version 2.4 PL25+pgp] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello everybody! I have been considering adding POSIX.4 extended signals in FreeBSD (practically the same patch could be applied to any 4.4BSD system, I guess). There is this very odd thing about 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. A typical example of the kind of change that would have to be done is from tty.c ... - (p->p_sigignore & sigmask(SIGTTOU)) == 0 && - (p->p_sigmask & sigmask(SIGTTOU)) == 0) { + ! sigismember (&p->p_sigignore, SIGTTOU) && + ! sigismember (&p->p_sigmask, SIGTTOU)) { Without a number this kind of changes it would be impossible to add the new extended signals. The type sigset_t would then have to become an array of maybe four unsigned int's or a struct 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 gone on using the same assumption of a plain integer sigset_t model and they would break, if I changed only the kernel to support the new POSIX.4 signal model. Yet another potential problem I found was that, because all the longjmp() etc. calls have been implemented in iX86 assembly, it takes also a separate effort to make them work right with the extended signal set. So, I guess this all boils down to the simple question... Is there anyone else out there who would be interested in this kind of effort? BTW... Now that I have started asking there is also another question I have been wondering... What is the most reliable way to select a common memory address inside the 4.4BSD kernel for an object which has been mmap()ed as shared by multiple processes? I would like to make pick such an address so that any processes sharing the same object could be put sleeping on that very address until some other process sends a "go ahead" message to them. Maybe the macro vtophys from machine/pmap.h would be OK? Oh yes, you may have guessed it. I am thinking about adding in the kernel support for semaphores settable by user processes, including the counting semaphore model from POSIX.4. POSIX.4 message queues might come practically free with the semaphores, because I have POSIX.4 shared memory routines already which combined with the semaphores form the basis for the message queues anyway. It would also be really interesting to know whether anyone from the mmap() people has been working on the new mlockall(2) and munlockall(2) stuff that was defined by POSIX.4. Cheers, // jau ------ / Jukka A. Ukkonen, FUNET / Centre for Scientific Computing /__ M.Sc. (sw-eng & cs) Tel: (Home&Fax) +358-0-6215280 / Internet: ukkonen@csc.fi (Work) +358-0-4573208 v Internet: jau@funet.fi (Mobile) +358-400-606671