From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgCor-0001nG-1n for qemu-devel@nongnu.org; Fri, 02 May 2014 08:44:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WgCoj-0001FB-IA for qemu-devel@nongnu.org; Fri, 02 May 2014 08:44:00 -0400 Received: from afflict.kos.to ([92.243.29.197]:47842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgCoj-0001Ed-Ag for qemu-devel@nongnu.org; Fri, 02 May 2014 08:43:53 -0400 Date: Fri, 2 May 2014 15:43:51 +0300 From: Riku Voipio Message-ID: <20140502124351.GA5296@afflict.kos.to> References: <1398781051-16207-1-git-send-email-ncopa@alpinelinux.org> <1398781051-16207-6-git-send-email-ncopa@alpinelinux.org> <535FB70D.5070304@redhat.com> <20140429165358.45c092a0@ncopa-desktop.alpinelinux.org> <535FBEF5.5070001@redhat.com> <20140429220631.732ed7c3@ncopa-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140429220631.732ed7c3@ncopa-laptop> Subject: Re: [Qemu-devel] [PATCH 5/5] linux-user/signal.c: define __SIGRTMIN/MAX for non-GNU platforms List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Natanael Copa Cc: qemu-devel@nongnu.org On Tue, Apr 29, 2014 at 10:06:31PM +0200, Natanael Copa wrote: > On Tue, 29 Apr 2014 09:02:13 -0600 > Eric Blake wrote: > > > On 04/29/2014 08:53 AM, Natanael Copa wrote: > > > On Tue, 29 Apr 2014 08:28:29 -0600 > > > Eric Blake 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