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

[Jeff Johnston]

Christopher Faylor wrote:
> On Mon, Oct 04, 2004 at 06:47:03PM -0400, Jeff Johnston wrote:
> 
>>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?  I think most systems (at least the
>>>ones I checked) tend to make sys/signal.h == signal.h.
>>
>>The basis of the current design is that signal numbers are considered OS 
>>specific and newlib tries to separate such header information into sys 
>>headers - the idea being that an OS using newlib simply overrides the sys 
>>header file as needed.  Newlib doesn't have a bits directory - it has a 
>>machine directory.  It also does not have an OS-specific header directory 
>>like /usr/include/linux.  Is it fair to guess you are having problems with 
>>applications that simply include <sys/signal.h> and not <signal.h>?
> 
> 
> Someone just posted a patch for some software which added an '#ifdef
> __CYGWIN__' and forced an include of <signal.h> rather than
> <sys/signal.h>.  It had been a while since I looked at how this was laid
> out and I was surprised to see a handful of definitions in signal.h with
> the majority of definitions in sys/signal.h.
> 
> If this is system-specific stuff then some things should be moved out of
> sys/signal.h, it seems.  It looks like sigset_t should be moved into
> signal.h along with SIG_SETMASK, SIG_BLOCK, and SIG_UNBLOCK, sigaddset,
> sigemptyset, and sigprocmask.
>
> I'm not sure who's benefitting from this split, though.  AFAICT, the fact
> that linux has a bits directory is irrelevant since the linux versions
> of /usr/include/sys/signal.h and /usr/include/signal.h are the same thing.
> How things are defined under the hood doesn't really matter as far as
> the end-programmer is concerned.
> 
> cgf

There is also the ANSI <signal.h> vs POSIX signal handling aspect to think 
about.  A lot of additional items in the current <sys/signal.h> are RTEMS and 
CYGWIN adding POSIX signal-handling.  In theory, both OSes probably should have 
had their own <sys/signal.h> in their respective directories rather than 
cluttering up the file with #ifdefs but I'm ok with what we have now.  Anything 
supported by newlib for all platforms should exist in <signal.h>.  For example, 
sigset_t certainly applies since sigset.c is in the unix directory.  It should 
be defined as __sigset_t to allow <sys/types> or <sys/signal.h> to override the 
definition.

<sys/signal.h> is not defined by POSIX, ANSI, Single UNIX, or C99 so we're 
largely in undefined territory here.  As previously noted, newlib's usage of the 
sys directory doesn't necessarily match up with other C libraries out there.  It 
seems to me the ultimate goal you want to achieve is to allow existing code 
written against glibc that takes advantage of the fact that <signal.h> and 
<sys/signal.h> are interchangeable.  An easy solution would be to add a check in 
the default <sys/signal.h> that if _SIGNAL_H_ wasn't already defined, to include 
<signal.h>.  Does that seem reasonable to you?

-- Jeff J.

-- Jeff J.