Date: Wed, 26 Jun 1996 22:35:51 +0300 (EET DST) From: Jukka Ukkonen <jau@jau.csc.fi> To: hackers@freebsd.com Subject: POSIX.4 signals + other POSIX.4 stuff to FreeBSD... Message-ID: <199606261935.WAA19711@jau.csc.fi>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606261935.WAA19711>