Re: Update siginfo constants from Linux kernel (bug 21286)

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.