Bug 1371533 - kernel-headers should provide SYS_ macros
Summary: kernel-headers should provide SYS_ macros
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1371535
TreeView+ depends on / blocked
 
Reported: 2016-08-30 12:18 UTC by Florian Weimer
Modified: 2017-10-11 12:12 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-11 12:12:55 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1484729 0 unspecified CLOSED glibc: Use an arch-independent system call list 2021-02-22 00:41:40 UTC

Internal Links: 1484729

Description Florian Weimer 2016-08-30 12:18:14 UTC
Currently, we extract a list of __NR_ macros from the kernel headers and generate SYS_ aliases for them.

This has the effect that the SYS_ variant of new system call #defines becomes available only after glibc is recompiled with an updated kernel-headers package.  This is confusing to developers.

I would prefer if the kernel-headers could generate the SYS_ list instead and activate it if glibc defines a special macro (so that backwards compatibility with older glibc headers is not impacted).  Alternatively, the kernel headers could define a macro which indicates that a file with SYS_ alias #defines is available in a specific location.

I would like to implement this change upstream, but found the build system and the cross-architecture variance a bit confusing.  As far as I can tell, the __NR_ macros are only auto-generated on some architectures.  Help with that would be appreciated.

Comment 1 Florian Weimer 2017-10-11 12:12:55 UTC
We changed the SYS_ generation in glibc upstream, so this is no longer needed.


Note You need to log in before you can comment on or make changes to this bug.