From: Florian Weimer <fweimer@redhat.com>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Joseph Myers <joseph@codesourcery.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
libc-alpha@sourceware.org, Thomas Gleixner <tglx@linutronix.de>,
Ben Maurer <bmaurer@fb.com>,
Peter Zijlstra <peterz@infradead.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Boqun Feng <boqun.feng@gmail.com>,
Will Deacon <will.deacon@arm.com>,
Dave Watson <davejwatson@fb.com>, Paul Turner <pjt@google.com>,
Rich Felker <dalias@libc.org>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH glibc 2.31 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v12)
Date: Wed, 11 Sep 2019 21:54:23 +0200 [thread overview]
Message-ID: <877e6er4ls.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <4a6f6326-ea82-e031-0fe0-7263ed97e797@redhat.com> (Carlos O'Donell's message of "Wed, 11 Sep 2019 15:45:14 -0400")
* Carlos O'Donell:
> On 9/11/19 3:08 PM, Florian Weimer wrote:
>> * Carlos O'Donell:
>>
>>> It would be easier to merge the patch set if it were just an unconditional
>>> registration like we do for set_robust_list().
>>
>> Note that this depends on the in-tree system call numbers list, which I
>> still need to finish according to Joseph's specifications.
>
> Which work is this? Do you have a URL reference to WIP?
<https://sourceware.org/ml/libc-alpha/2019-05/msg00630.html>
<https://sourceware.org/ml/libc-alpha/2019-06/msg00015.html>
I think realistically this is needed for the Y2038 work as well if we
want to support building glibc with older kernel headers. “glibc 2.31
will have Y2038 support and rseq support, but only if it runs on a
current and it happens to have been built against sufficiently recent
kernel headers” is a bit difficult to explain. The current kernel part
is easy enough to understand, but the impact of the kernel headers on
the feature set has always been tough to explain. Especially if you
factor in vendor kernels with system call backports.
Thanks,
Florian
next prev parent reply other threads:[~2019-09-11 19:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190807142726.2579-1-mathieu.desnoyers@efficios.com>
2019-08-07 14:27 ` [PATCH glibc 2.31 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v12) Mathieu Desnoyers
2019-09-11 18:26 ` Florian Weimer
2019-09-11 19:00 ` Carlos O'Donell
2019-09-11 19:08 ` Florian Weimer
2019-09-11 19:45 ` Carlos O'Donell
2019-09-11 19:54 ` Florian Weimer [this message]
2019-09-11 19:58 ` Florian Weimer
2019-09-11 20:08 ` Rich Felker
2019-09-13 15:58 ` Mathieu Desnoyers
2019-09-14 1:36 ` Florian Weimer
2019-08-07 14:27 ` [PATCH glibc 2.31 2/5] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux (v5) Mathieu Desnoyers
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=877e6er4ls.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=bmaurer@fb.com \
--cc=boqun.feng@gmail.com \
--cc=carlos@redhat.com \
--cc=dalias@libc.org \
--cc=davejwatson@fb.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=szabolcs.nagy@arm.com \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.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.
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).