From owner-freebsd-hackers Fri Jun 28 14:58:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA02396 for hackers-outgoing; Fri, 28 Jun 1996 14:58:07 -0700 (PDT) Received: from jau.csc.fi (root@jau.csc.fi [193.166.1.196]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA02380 for ; Fri, 28 Jun 1996 14:57:39 -0700 (PDT) Received: (from jau@localhost) by jau.csc.fi (8.7.5/8.6.12+CSC-2.1) id TAA22857; Fri, 28 Jun 1996 19:32:05 +0300 (EET DST) From: Jukka Ukkonen Message-Id: <199606281632.TAA22857@jau.csc.fi> Subject: Re: POSIX.4 signals + other POSIX.4 stuff to FreeBSD... To: terry@lambert.org (Terry Lambert) Date: Fri, 28 Jun 1996 19:32:04 +0300 (EET DST) Cc: bde@zeta.org.au, hackers@freebsd.com In-Reply-To: <199606271833.LAA05478@phaeton.artisoft.com> from "Terry Lambert" at Jun 27, 96 11:33:41 am Latin-Date: Vineri XXVIII 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 Quoting Terry Lambert: > > Use the extended structure size only in the extension interfaces, and > assume defaults for the non-extension interfaces (you will have to > do this as part of the ABI mapping in any case). I did something > similar to this for the fcntl() calls for NFS server locking, which > requires system and process ID's for the proxy. Eh? As I already said, the new and the old call interface would have to co-exist for some time, so that the old programs using the old interface would not break. (This might prove out to be a slippery road to take, but maybe it would be possible. I don't know about the shared libraries though.) There are only three completely new system calls or functions defined by POSIX.4 for the signals. extern int sigqueue __P((pid_t, int, const union sigval)); extern int sigwaitinfo __P((const sigset_t *, siginfo_t *)); extern int sigtimedwait __P((const sigset_t *, siginfo_t *, const struct timespec *)); The new or modified data structures in POSIX.4 are as follows... union sigval { int sival_int; void *sival_ptr; /* Remember to cast this correctly! */ }; struct sigevent { int sigev_notify; /* SIGEV_SIGNAL or SIGEV_NONE */ int sigev_signo; /* signal to raise for this event */ union sigval sigev_value; /* queue the signal with this value */ }; struct siginfo { int si_signo; /* redundant signal number */ int si_code; /* facility that raised this signal */ union sigval si_value; /* value that was queued with signal */ }; typedef struct siginfo siginfo_t; #define SIGEV_NONE 0 /* don't notify */ #define SIGEV_SIGNAL 1 /* use signals for notification */ #define SIGEV_THREAD 2 /* from POSIX.4a - the threads */ #define SI_USER 0x01 /* sent without data by application code */ #define SI_QUEUE 0x02 /* sent with data by application code */ #define SI_TIMER 0x04 /* raised by an expired timer */ #define SI_ASYNCIO 0x08 /* raised by completed async. I/O */ #define SI_MESGQ 0x10 /* data waiting in a message queue */ /* * Signal vector "template" used in sigaction call. */ struct sigaction { union { /* * These two could be separate fields quite as well. * * Either a simple POSIX.1 signal handler * with additional BSD style parameters ... */ void (*sa_handler) _P((int, ...)); /* * ... or a more complex POSIX.4 signal handler */ void (*sa_sigaction) _P((int, siginfo_t *, void *)); }; sigset_t sa_mask; /* signal mask to apply */ int sa_flags; /* see signal options below */ }; POSIX.4 also adds the flag SA_SIGINFO which enables the real-time queueing signal behaviour. When SA_SIGINFO is set the handler has to be able to accept the new sa_sigaction type parameter list. Otherwise the old sa_handler type parameter list should be used. All the rest of the signals system is just as before and the old call interface is expected to be able to operate also with the new RT-signals. These are just kind of added USRxx signals. The extended functionality of the signals system call interface is very much a distinct idea. The increased number of user definable signals is there just to make useful the new more complex functionality of the call interface. Though Bruce Evans seems not to share my opinion, I suppose using sigismember() etc. macros/functions within the kernel would not be very much a resource hog, or what do you think of the next macro? #define sigismember(set, sig) (set[((unsigned) (sig)) >> 5] \ & (1 << ((sig) & 0x1F))) This does not really require too many extra machine instructions when used instead of the simple bitwise and/or logic. This already accounts for the ability to handle an extended signal set. 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