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