qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 5/5] linux-user/signal.c: define __SIGRTMIN/MAX


From: Riku Voipio
Subject: Re: [Qemu-devel] [PATCH 5/5] linux-user/signal.c: define __SIGRTMIN/MAX for non-GNU platforms
Date: Fri, 2 May 2014 15:43:51 +0300
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Apr 29, 2014 at 10:06:31PM +0200, Natanael Copa wrote:
> On Tue, 29 Apr 2014 09:02:13 -0600
> Eric Blake <address@hidden> wrote:
> 
> > On 04/29/2014 08:53 AM, Natanael Copa wrote:
> > > On Tue, 29 Apr 2014 08:28:29 -0600
> > > Eric Blake <address@hidden> 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?
 
> Yeah, that might be an idea.

If you can update the patch with asserts, I'd be fine with the patch.
I don't we want to go into changing to use NSIG-1 unless there is some
compelling advantage on it. 

> > > /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.
> > 
> 
> Since we already use _NSIG to define the size of the array, and we want
> to use the last element of the array, maybe we should just use _NSIG-1?
> 
> -nc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]