Consensus around kernel syscall wrappers?

[Florian Weimer]

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