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

[Ingo Molnar <mingo@kernel.org>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Aug 25, 2015 21:49, "Ingo Molnar" <mingo@kernel.org> 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.

So the prctl() suggestion would address that worry, which would make it available 
essentially immediately, for any tool that cares. (And this would IMHO be a 
prctl() that kind of fits the interface, it does not feelt bolted on.)

Internationalization could be done easily in a user-space library, by hash-tabling 
the English strings - for anyone who cares. It could be a simple free-form 
string->string translation library that gets strings added, it doesn't have to 
know about any context.

> We've had this before. Some extension that is Linux-specific, and improved on 
> some small detail, and never gets used, and just cause pain.

I think this time is different, especially with another interface variant we could 
use that I think addresses (most of your) concerns:

> And the extended errors would be painful even in the kernel. We do compare for 
> specific error values. As does user space. There is a reason those values are 
> limited to a fairly small set of standard values, and system calls come with 
> documentation on which errors they can return.

So my very first interface suggestion two years ago when this first came up was to 
decouple the error code from the string, i.e. to allow:

	return err_code(-EINVAL, "x86/perf: CPU does not support precise sampling");

... which would return -EINVAL all the way - but would side-store the error 
string, for user-space that requests it. There would be no 'extended errno' space 
at all, dynamic or static, just the regular errno, and an optional string for 
user-space that wants to use it.

This would make error codes still tightly clustered around a handful of main 
categories and there would be no change whatsoever to current error codes.

Would you be fine with such an approach?

> It may work for perf, but don't start thinking it works anywhere else

Ok, will keep it perf (and scheduler) only.

Thanks,

	Ingo