On 04/29/2014 08:53 AM, Natanael Copa wrote: > On Tue, 29 Apr 2014 08:28:29 -0600 > Eric Blake <ebl...@redhat.com> wrote: > >> On 04/29/2014 08:17 AM, Natanael Copa wrote: >>> The __SIGRTMIN and __SIGRTMAX are glibc internals and are not available >>> on all platforms, so we define those if they are missing.
>>> +#define __SIGRTMIN 32 >> >> Rather than defining the implementation-specific __SIGRTMIN to a magic >> number that is liable to be wrong, why not instead fix the code to use >> the POSIX-mandated SIGRTMIN and SIGRTMAX public defines instead? >> > > Those seems to be runtime values: > /usr/include/signal.h:#define SIGRTMIN (__libc_current_sigrtmin()) Oh right - POSIX allows them to be runtime variable. But we are interacting with a given kernel, where the values will be fixed. Maybe you have to define __SIGRTMIN after all, but can we at least have an assert() that the value you picked matches SIGRTMIN at runtime? > /usr/include/signal.h:#define SIGRTMAX (__libc_current_sigrtmax()) > > so it gives: > /home/ncopa/src/qemu/linux-user/signal.c:93:5: error: nonconstant array index > in initializer > [SIGRTMIN] = __SIGRTMAX, > > I could have used (NSIG-1) but are not sure if NSIG is a runtime macro > in glibc. The array itself is using _NSIG instead of NSIG for some > reason. NSIG is not any more portable; nor does POSIX require that the RT signals occur at the tail end of NSIG (in other words, NSIG-1 need not be SIGRTMAX). Unless someone knows of a kernel define, it sounds like we're stuck hard-coding in some knowledge of Linux. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
