[ Context for Linus: I am dropping this RFC patch, but am curious to hear your point of view on exposing to user-space which system call behavior fixes are present in the kernel, either through feature flags or system-call versioning. The intent is to allow user-space to make better decisions on whether it should use a system call or rely on fallback behavior. ]
----- On Jul 7, 2020, at 3:55 PM, Florian Weimer f...@deneb.enyo.de wrote: > * Carlos O'Donell: > >> It's not a great fit IMO. Just let the kernel version be the arbiter of >> correctness. > > For manual review, sure. But checking it programmatically does not > yield good results due to backports. Even those who use the stable > kernel series sometimes pick up critical fixes beforehand, so it's not > reliable possible for a program to say, “I do not want to run on this > kernel because it has a bad version”. We had a recent episode of this > with the Go runtime, which tried to do exactly this. FWIW, the kernel fix backport issue would also be a concern if we exposed a numeric "fix level version" with specific system calls: what should we do if a distribution chooses to include one fix in the sequence, but not others ? Identifying fixes are "feature flags" allow cherry-picking specific fixes in a backport, but versions would not allow that. That being said, maybe it's not such a bad thing to _require_ the entire series of fixes to be picked in backports, which would be a fortunate side-effect of the per-syscall-fix-version approach. But I'm under the impression that such a scheme ends up versioning a system call, which I suspect will be a no-go from Linus' perspective. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
