[Ksummit-discuss] [MAINTAINER TOPIC] ABI feature gates?
Julia Lawall
julia.lawall at lip6.fr
Fri Aug 4 15:47:24 UTC 2017
On Fri, 4 Aug 2017, Theodore Ts'o wrote:
> On Fri, Aug 04, 2017 at 07:13:10AM +0200, Julia Lawall wrote:
> > I did some work on a semantic patch for collecting the error codes
> > returned by all of the system class. Things were going fairly well until
> > I discovered that is fairly common near the user level to return error
> > codes in reference parameters rather than by direct returns, and that
> > meant that I was going to have to duplicate my entire rule set. I also
> > observed that the documentation is not always that precise. It will say
> > typically returns -E1, -E2, -E3, and may return other stuff, so in that
> > case there is less to check.
>
> Yeah, including potential new error returns as "changes to the
> ABI/API" is probably simply not practical. Adding a return for, say,
> ENOMEM instead of causing a kernel oops is not something that needs to
> be debated on the linux-api mailing list!
>
> I recall, many years ago, an executive being indignant because Linux
> was returning some error code for some syscall operation involving
> network file system because it returned an network-related errno that
> was not explicitly listed in POSIX for a file system related syscall,
> and demanded that we fix the problem. I had to gently point out to
> said gentleman (since I was working for the Linux Foundation at the
> time and he worked for a platinum sponsor :-) that POSIX as a blanket
> statment allows confirming implementations' system calls to return
> additional error codes as necessary.
>
> I think people are much more concerned when there is a new system
> call, or a new flag added to a core syscall (e.g., O_TMPFILE). I
> suspect that we required all new device ioctls and new flags to device
> ioctls to get the linux-api@ treatment that we would get mass
> resistance and the workload would not be practical. And this list
> doesn't even consider new sysfs files, new tracepoints, etc., etc.
I guess that new stsem calls would be easy to recognize, if they all start
with SYSCALL_DEFINE1, etc?
New flags could be #defines that are added to uapi .h file and that are
used in some similar way to other flags mentioned in the documentation?
So if the code already contains eg x & O_APPEND and there appears x &
O_TMPFILE and the documentation mentions O_APPEND, then it should now
mention O_TMPFILE too?
julia
>
> Although technically speaking this is all "API's" I think we need to
> pick our battles and start with a tractable subset of the problem...
>
> - Ted
>
More information about the Ksummit-discuss
mailing list