This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update siginfo constants from Linux kernel (bug 21286)
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 3 Sep 2018 07:30:34 -0700
- Subject: Re: Update siginfo constants from Linux kernel (bug 21286)
- References: <alpine.DEB.2.21.1808301557410.4027@digraph.polyomino.org.uk> <CAMe9rOo4WVe6peMR=jHCU3SvU-9ABWinskaybWsRzt492_WNyQ@mail.gmail.com> <alpine.DEB.2.21.1809031348110.9070@digraph.polyomino.org.uk>
On Mon, Sep 3, 2018 at 6:51 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 3 Sep 2018, H.J. Lu wrote:
>
>> > diff --git a/sysdeps/unix/sysv/linux/bits/siginfo-consts.h b/sysdeps/unix/sysv/linux/bits/siginfo-consts.h
>> > index 193bd9c471..d69d27d922 100644
>> > --- a/sysdeps/unix/sysv/linux/bits/siginfo-consts.h
>> > +++ b/sysdeps/unix/sysv/linux/bits/siginfo-consts.h
>> > @@ -35,7 +35,9 @@
>> > enum
>> > {
>> > SI_ASYNCNL = -60, /* Sent by asynch name lookup completion. */
>> > - SI_TKILL = -6, /* Sent by tkill. */
>> > + SI_DETHREAD = -7, /* Sent by execve killing subsidiary
>> > + threads. */
>>
>> Wasn't SI_DETHREAD there in 2012? Should it be a separate patch?
>
> The patch is generically making the header reflect the current set of
> constants in the kernel, without regard to when the kernel added them in
> what header.
A separate patch for SI_DETHREAD is much easier to review. It
may be useful for backport. Can you make a separate patch for
SI_DETHREAD?
>> Why are only parts of it implemented here?
>
> As I said:
>
> Nothing is done about macros that are defined in
> include/uapi/asm-generic/siginfo.h with names with leading '__' (some
> of those are ia64-specific ones that remain in the ia64
> bits/siginfo-consts-arch.h without the leading '__' there).
>
> If the kernel defines __SOMETHING in the generic header, I'm not treating
> that as meaning that SOMETHING without the leading '__' should thereby
> become part of the generic API (whether or not it is part of the ia64
> API).
>
That makes senses.
Thanks.
--
H.J.