SIGPOLL is not defined in <sys/ioctl_compat.h>. This macro is required by XSI: http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html Since SIGPOLL is basicaly a the same thing as SIGIO, it's safe to give it the same number (this is what GNU/Linux does). Patch below.
Responsible Changed From-To: freebsd-bugs->freebsd-standards Pass to standards list for review.
The OP's claim is wrong. SIGIO is a signal that can be discarded, whereas SIGPOLL by definition terminates processes. From SUSv7 (pardon the poor formatting): The following signals shall be supported on all implementations (default actions are explained below the table): Signal Default Action Description SIGPOLL T Pollable event. T Abnormal termination of the process. The process is terminated with all the consequences of _exit() except that the status made available to wait() and waitpid() indicates abnormal termination by the specified signal. From signal(3) (pardon the poor formatting): 23 SIGIO discard signal I/O is possible on a descriptor (see fcntl(2)) SIGPOLL is actually somewhere between SIGIO and SIGIOT (SIBABRT), but there isn't a 1:1 mapping for the signal definition. This is also XSI Stream specific (which is not [fully] implemented in [Free]BSD). SIGIO is also used by fcntl(2) to denote when I/O is available, but this connotation is not noted in SUSv7 either. This item should probably be closed as WONTFIX as we don't implement SIGPOLL in its proper form. Thanks, -Garrett PS FWIW GNU/Linux needs to be educated on the fact that SIGIO is a discardable signal on other platforms and not an alias for SIGPOLL on BSD (especially when they use it as an alias but don't document the requirement >:(...), because a quick look at some glibc and Linux headers shows that they are using them as a 1:1 mapping (I am using Fedora 13 as a reference).
State Changed From-To: open->closed Firstly, note that SIGPOLL is under the XSI option, which FreeBSD does not attempt to implement completely. (In SUSv4, it's even Obsolescent XSI STREAMS. We do not have STREAMS in FreeBSD.) Secondly, I don't think our siginfo-less default-to-ignore SIGIO is going to help a SIGPOLL-using program much.