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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.