Messages in this thread | | | Date | Thu, 19 Mar 1998 14:50:35 -0800 | From | David Dyck <> | Subject | Re: signal names |
| |
Thanks Richard,
I knew that bash printed out a map of the signal names (with kill -l), but I didn't follow through to lookup how they did it.
I've now looked into mksignames.c, and have noticed several problems:
Although the linux headers map both SIGABRT and SIGIOT to signal 6, and linux also equates SIGPOLL to SIGIO as signal 29, so bash's list doesn't include SIGIOT or SIGPOLL.
Perl (which uses metaconfig) does list both names for each of the above listed duplicately name signals Perl also discovers SIGCLD mentioned in /usr/include/signal.h
Also bash mapped SIGSTKFLT (number 16) to "SIGJUNK(16)", and signal 31 (SIGUNUSED) to SIGJUNK(31).
Bash starts out with a predifined list of which signals it knows about and that causes it not to find new signals. On Solaris, the predefind approach cause bash to not list signals SIGWAITING, SIGLWP, SIGFREEZE, SIGTHAW, SIGCANCEL, as well as the SIGRTMIN/SIGRTMAX family of signals. [ I'll have to report this the bash bug list ]
On solaris, perl's aproach finds these signals.
The problem is still with the linux 2.1.x headers.
It is very strange that _NSIG is 64 but NSIG is only 32.
Since SIGRTMAX can not be evaluated in a user program unless __KERNEL__ is defined (which I assume makes it not a 'user' program) I think in the short term that we should add #ifdef __KERNEL__ arount the definitions of SIGRTMIN and SIGRTMAX in include/asm*/signal.h whenever SIGRTMAX is defined as a function of _NSIG.
Perhaps this should be forwarded directly to Linus, or whoever is responsible for the signal.h files. I tried to submit an official patch for this in 2.1.89, but it didn't get into 2.1.90.
David Dyck
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |