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 check-installed-headers.sh (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 joseph@xxxxxxxxxxxxxxxx
