mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] Separate siginfo_t for MIPS
Date: Tue, 15 Dec 2015 23:34:28 -0500	[thread overview]
Message-ID: <20151216043428.GC238@brightrain.aerifal.cx> (raw)
In-Reply-To: <20151210123633.GD23362@port70.net>

On Thu, Dec 10, 2015 at 01:36:33PM +0100, Szabolcs Nagy wrote:
> * Dmitry Ivanov <dmitrijs.ivanovs@ubnt.com> [2015-12-10 12:47:12 +0200]:
> > MIPS has non-default siginfo_t structure. Also, some si_code values are
> > different. This patch is required for POSIX timers to work.
> > 
> > ---
> >  arch/aarch64/bits/siginfo.h    |  0
> >  arch/arm/bits/siginfo.h        |  0
> >  arch/i386/bits/siginfo.h       |  0
> >  arch/microblaze/bits/siginfo.h |  0
> >  arch/mips/bits/siginfo.h       | 52 ++++++++++++++++++++++++++++++++++++++++++
> >  arch/or1k/bits/siginfo.h       |  0
> >  arch/powerpc/bits/siginfo.h    |  0
> >  arch/sh/bits/siginfo.h         |  0
> >  arch/x32/bits/siginfo.h        |  0
> >  arch/x86_64/bits/siginfo.h     |  0
> >  include/signal.h               |  7 ++++++
> >  11 files changed, 59 insertions(+)
> >  create mode 100644 arch/aarch64/bits/siginfo.h
> >  create mode 100644 arch/arm/bits/siginfo.h
> >  create mode 100644 arch/i386/bits/siginfo.h
> >  create mode 100644 arch/microblaze/bits/siginfo.h
> >  create mode 100644 arch/mips/bits/siginfo.h
> >  create mode 100644 arch/or1k/bits/siginfo.h
> >  create mode 100644 arch/powerpc/bits/siginfo.h
> >  create mode 100644 arch/sh/bits/siginfo.h
> >  create mode 100644 arch/x32/bits/siginfo.h
> >  create mode 100644 arch/x86_64/bits/siginfo.h
> > 
> > diff --git a/arch/aarch64/bits/siginfo.h b/arch/aarch64/bits/siginfo.h
> > new file mode 100644
> > index 0000000..e69de29
> > diff --git a/arch/arm/bits/siginfo.h b/arch/arm/bits/siginfo.h
> > new file mode 100644
> > index 0000000..e69de29
> > diff --git a/arch/i386/bits/siginfo.h b/arch/i386/bits/siginfo.h
> > new file mode 100644
> > index 0000000..e69de29
> > diff --git a/arch/microblaze/bits/siginfo.h b/arch/microblaze/bits/siginfo.h
> > new file mode 100644
> > index 0000000..e69de29
> > diff --git a/arch/mips/bits/siginfo.h b/arch/mips/bits/siginfo.h
> > new file mode 100644
> > index 0000000..42dbdf5
> > --- /dev/null
> > +++ b/arch/mips/bits/siginfo.h
> > @@ -0,0 +1,52 @@
> > +#define HAVE_ARCH_SIGINFO_T
> > +
> 
> HAVE_... is not in the reserved namespace of the implementation
> 
> > +#undef SI_ASYNCIO
> > +#undef SI_TIMER
> > +#undef SI_MESGQ
> > +#define SI_ASYNCIO  -2 /* sent by AIO completion */
> > +#define SI_TIMER    -3 /* sent by timer expiration */
> > +#define SI_MESGQ    -4 /* sent by real time mesq state change */
> > +
> 
> negative numbers must be parethesized.
> 
> and musl doesn't use such comments in public headers
> (they might be copyrightable).
> 
> > +/* We can't use generic siginfo_t, because our si_code and si_errno are swapped */
> > +typedef struct {
> > +	int si_signo, si_code, si_errno;
> 
> is this reordering the only change?
> (other than the SI_ macros)
> 
> the ifdef and empty siginfo.h files are not nice,
> there are some plans to change bits/* to make
> this kind of arch specific changes less painful.

Either way there's no need to add a new bits header. bits/signal.h
would be a perfectly good place for this.

> until then i think it's enough to fix it in signal.h
> with some dirty ifdef around these members.

Indeed, I think a makeshift solution could work okay here and avoid
moving this large, redundant structure into bits/signal.h. However I'd
rather not depend on compiler-predefined macros (like __mips__ in
Dmitry's second patch) in public headers, since we don't assume
particular compilers for compiling applications.

Ideally bits/signal.h would define something in the reserved namespace
to change the behavior of the top-level signal.h. However
bits/signal.h needs to be towards the bottom of signal.h for other
reasons, so I don't see a really clean solution. Ideas?

One principle this is suggesting to me for the bits deduplication &
refactoring is that perhaps _all_ ABI-level definitions should be in
bits/*.h rather than the top-level headers. Although if we go this
way, we need a way for bits/%.h to be generated from multiple
templates since some parts of a given bits file will be fairly generic
while others vary on almost every arch.

Rich


  parent reply	other threads:[~2015-12-16  4:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10 10:47 Dmitry Ivanov
2015-12-10 12:36 ` Szabolcs Nagy
2015-12-10 13:49   ` [PATCH v2] Different " Dmitry Ivanov
2015-12-16  4:34   ` Rich Felker [this message]
2016-01-26 22:24     ` [PATCH] Separate " Szabolcs Nagy
2016-01-26 22:57       ` Rich Felker
2016-01-26 23:32         ` Szabolcs Nagy
2016-01-27  1:03           ` Szabolcs Nagy
2016-01-27  3:33             ` Rich Felker

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=20151216043428.GC238@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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).