From: Riku Voipio <riku.voipio@iki.fi>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: qemu-devel@nongnu.org
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 [thread overview]
Message-ID: <20140502124351.GA5296@afflict.kos.to> (raw)
In-Reply-To: <20140429220631.732ed7c3@ncopa-laptop>
On Tue, Apr 29, 2014 at 10:06:31PM +0200, Natanael Copa wrote:
> On Tue, 29 Apr 2014 09:02:13 -0600
> Eric Blake <eblake@redhat.com> wrote:
>
> > On 04/29/2014 08:53 AM, Natanael Copa wrote:
> > > On Tue, 29 Apr 2014 08:28:29 -0600
> > > Eric Blake <eblake@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?
> 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
next parent reply other threads:[~2014-05-02 12:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1398781051-16207-1-git-send-email-ncopa@alpinelinux.org>
[not found] ` <1398781051-16207-6-git-send-email-ncopa@alpinelinux.org>
[not found] ` <535FB70D.5070304@redhat.com>
[not found] ` <20140429165358.45c092a0@ncopa-desktop.alpinelinux.org>
[not found] ` <535FBEF5.5070001@redhat.com>
[not found] ` <20140429220631.732ed7c3@ncopa-laptop>
2014-05-02 12:43 ` Riku Voipio [this message]
2014-06-04 7:49 ` [Qemu-devel] [PATCH v2] linux-user/signal.c: define __SIGRTMIN/MAX for non-GNU platforms Natanael Copa
2014-06-06 8:27 ` Riku Voipio
2014-06-06 9:48 ` Paolo Bonzini
2014-05-02 13:06 ` [Qemu-devel] [PATCH 0/5] fix building with musl libc Paolo Bonzini
2014-06-03 23:37 ` Peter Maydell
2014-06-04 5:56 ` Natanael Copa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140502124351.GA5296@afflict.kos.to \
--to=riku.voipio@iki.fi \
--cc=ncopa@alpinelinux.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).