This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus around kernel syscall wrappers?
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Mike Frysinger <vapier at gentoo dot org>, Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 17 Aug 2015 21:45:42 +0200
- Subject: Re: Consensus around kernel syscall wrappers?
- Authentication-results: sourceware.org; auth=none
- References: <55CCF8C6 dot 3060007 at redhat dot com> <55D237F7 dot 3050002 at redhat dot com> <55D238F7 dot 8030505 at redhat dot com>
On 08/17/2015 09:41 PM, Carlos O'Donell wrote:
> On 08/17/2015 03:37 PM, Florian Weimer wrote:
>> On 08/13/2015 10:06 PM, Carlos O'Donell wrote:
>>> Have we achieved consensus on the kernel syscall wrappers?
>>>
>>> https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
>>
>> I think it's worth adding another point, that the sole arbiter of the
>> Linux API is Linus' kernel tree. Which means we won't wrap system calls
>> (or ioctl constants) related to non-mainline extensions.
>
> Yes and no.
>
> There is precedent for doing some work early, but gating it on kernel version.
>
> https://sourceware.org/glibc/wiki/Style_and_Conventions#Support_for_features_not_yet_in_the_mainstream_Linux_kernel.3F
Why was this done in this way? I suspect because of the poor branching
capabilities of CVS. :-)
I don't think it's a reasonable way to do this today.
> So you could use kernel-features.h to disable the code until some future kernel
> version puts it in place.
What about things like Tux or the first iteration of the Secure Boot
support, which never went upstream, and eventually turned
ABI-incompatible? Do we really want to have this in the master tree,
even under a flag?
--
Florian Weimer / Red Hat Product Security