Re: [PATCH v2 0/6] perf: Introduce extended syscall error reporting

From: Ingo Molnar
Date: Wed Aug 26 2015 - 03:20:45 EST

* Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:

> On Tue, 2015-08-25 at 22:07 -0700, Linus Torvalds wrote:
> > > No, the current MAX_ERRNO is probably not big enough if this scheme is successful,
> > > and I don't see any reason why it wouldn't be successful: I think this feature
> > > would be the biggest usability feature added to Linux system calls and to Linux
> > > system tooling in the last 10 years or so.
> > Don't be silly. It's a horrible idea. People would want to
> > internationalize the strings etc, and nobody would use the extended
> > versions anyway, since nobody uses raw system calls.
> That's a good point, and think that least in the netlink case it'd be much
> better to say which attribute was the one that had an issue, and that has an
> obvious binary encoding rather than encoding that in a string.

So in older discussions about this I suggested a solution for that: also returning
(in a channel separate from errnos) the byte offset to the field that caused the
error, plus a string - and leaving errnos alone.

This only matters for those (few) system calls that have a large attribute space:
perf and some of the scheduler syscalls are such.

With this scheme arbitrarily granular error handling can be implemented:

- the laziest can just use the errno like usual, which catches 90% of the apps.

- the somewhat sophisticated would print the human readable string (or a
translation thereof). Would cover another 9%. (This percentage might increase
over time, as the strings become more widely used.)

- tools with a case of obsessive-compulsive perfectionism would use the structure
offset to programmatically react to the error condition, and would use the
human-readable string to explain the precise reason. Would cover another 1% of

... but back then I didn't feel like complicating an error recovery ABI for the
needs of the 1%, robust error handling is all about simplicity: if it's not
simple, tools won't use it.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at