Re: Moving everything from signal.h to sys/signal.h

[Ralf Corsepius <ralf_corsepius at rtems dot org>]

On Mon, 2004-10-04 at 06:37, Christopher Faylor wrote:
> On Mon, Oct 04, 2004 at 05:48:54AM +0200, Ralf Corsepius wrote:
> >On Mon, 2004-10-04 at 00:12, Christopher Faylor wrote:
> >> Is there any reason why there are a handful of definitions in
> >> libc/include/signal.h while most of the signal definitions are in
> >> libc/include/sys/signal.h?
> >signal.h's behavior is defined by standards (POSIX)
> >
> >sys/signal.h is an implementation detail used to hide away
> >arch-dependent details from signal.h
> 
> Did you look at what's in /usr/include/signal.h in newlib right now?
I have newlib-1.11.0, newlib-1.12.0 and newlib-cvs around.

And yes, I agree, some cleanup would not be a fault.

As I see it, the #ifdefs in sys/signal.h are not "a really good design",
but "functional for now". I.e. I think the way to go would be to make
signal.h to be to generalize signal.h as much as possible and to try
keeping arch-/sys-dependent stuff elsewhere (cf. bits/*, asm/* etc. in
Linux and machine/*, sys/* in BSD). 

ATM, this is what sys/signal.h is used for in newlib. It's a "catch all"
for arch- and sys-dependent signal.h requirements :).

> >>I think most systems (at least the ones I checked) tend to make
> >>sys/signal.h == signal.h.
> >Hmm?  All the ones I checked, do not.  Neither Linux, Solaris nor
> >Freebsd.
> 
> I don't know what version of linux you're looking at
FC2, and yes you are right, I was wrong, as far as linux is concerned.

However, Linux's has moved their machine/architecture dependent parts to
their bits/*.h. newlib "lumps them together" in sys/signal.h.

>  but I just
> checked an old version of Debian, RH9, and Fedora.  They all have
> a dummy version of /usr/include/sys/signal.h that looks like this:
> 
> #include <signal.h>
Yes, this is what I have, too.

> /usr/include/sys/signal.h is linked to /usr/include/signal.h on OSF/1.
Dated some time in the beginning of the 90's, I suppose ;)

> I don't think there is any consistent rationale for the current
> separation.
Agreed.

AFAICT, sys/signal.h originates from the BSD sourcetree layout, which
tries to apply a separation between application-API (/usr/include),
system/OS-API (/usr/include/sys/) and architecture/machine-API
(/usr/include/machine).

E.g. at least FreeBSD has signal.h, sys/signal.h and machine/signal.h.

Ralf