[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874kukpf9f.fsf@mid.deneb.enyo.de>
Date: Thu, 19 Mar 2020 15:53:48 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Mathieu Desnoyers via Libc-alpha <libc-alpha@...rceware.org>
Cc: Carlos O'Donell <carlos@...hat.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Rich Felker <dalias@...c.org>, linux-api@...r.kernel.org,
Boqun Feng <boqun.feng@...il.com>,
Will Deacon <will.deacon@....com>,
linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Ben Maurer <bmaurer@...com>, Dave Watson <davejwatson@...com>,
Thomas Gleixner <tglx@...utronix.de>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Paul Turner <pjt@...gle.com>,
Joseph Myers <joseph@...esourcery.com>
Subject: Re: [RFC PATCH glibc 4/8] glibc: Perform rseq(2) registration at C startup and thread creation (v15)
* Mathieu Desnoyers via Libc-alpha:
> Changes since v14:
> - Update copyright range to include 2020.
> - Introduce __ASSUME_RSEQ defined for --enable-kernel=4.18.0 and higher.
> - Use ifdef __ASSUME_RSEQ rather than ifdef __NR_rseq to discover rseq
> availability. This is necessary now that the system call numbers are
> integrated within glibc.
It's not quite clear to me why you need __ASSUME_RSEQ.
Can you use __has_include in <sys/rseq.h>, with a copy of the kernel
definitions if the kernel header is not available?
Powered by blists - more mailing lists