* Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Aug 25, 2015 21:49, "Ingo Molnar" <mi...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
