[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: POSIX.4 signals + other POSIX.4 stuff to FreeBSD...
From:       Terry Lambert <terry () lambert ! org>
Date:       1996-07-01 19:13:47
[Download RAW message or body]

> > 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.)

Sorry for the delay...

If it can be implemented without affecting binary compatability,
then it should be permitted.

If it must affect binary compatability, then I'm against it, and
would prefer assigning another call ID to the new method, and force
both to gate into the same code so the maintenance on the old call
can't be orphaned by neglect.

> 	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 *));

I prefer multiplex calls through a single call for this type of
thing: one call per subsystem interface to make it easier to
replace.


> 	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.

I have to agree with Bruce: yhe POSIX interfaces are there for the
applications, not the kernel.  It should be permissable to optimize
the hell out of the kernel, to the exclusion of POSIX macros from
kernel code to make it more efficient, as necessary.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

[prev in list] [next in list] [prev in thread] [next in thread]