[lkml]   [2019]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v6)
On Tue, 29 Jan 2019, Mathieu Desnoyers wrote:

> My thinking was to put the #error in the generic header, so architectures that
> are not supported yet cannot build against rseq.h at all, so we don't end up
> in a broken upgrade scenario. I'm open to alternative ways to do it though, as
> long as we don't let not-yet-supported architectures build broken code.

Any case with #error in installed glibc headers needs special-casing in (and, thus, such errors are to be discouraged).

Cases where architectures commonly need their own bits/ headers,
especially where those are likely to need updating for new kernel
versions, are also discouraged. Furthermore, a normal check for glibc
headers updates needed for a new kernel version would only involve
examining uapi headers (and the non-uapi linux/socket.h for new address
families, an unfortunate existing wart in this area). As far as I can
see, this value isn't defined in any uapi header, which makes it
especially likely to be missed in such a check. Furthermore, I'm hoping
to add more glibc tests for consistency of such constants between glibc
and the kernel, to ensure any such updates missing are caught
automatically through test failures - but that doesn't work if the
constants in question aren't in a uapi header.

If this constant were in a uapi header, the glibc header could just
include that - is the issue that it's not actually an interface between
glibc and the kernel at all, but some kind of purely-userspace interface?

We very definitely wish to keep to a minimum the cases where updates need
to be done separately in glibc by each architecture maintainer (that's
just a recipe for some updates getting missed accidentally) - meaning that
there needs to be a clear way in which someone can tell, globally for all
architectures, whether the set of such architecture-specific headers for
this constant in glibc is complete and current, and when it needs updating
(and this should be as similar to possible to such checks for any other
header constant).

Joseph S. Myers

 \ /
  Last update: 2019-01-30 03:42    [W:0.100 / U:4.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site