* Johannes Berg <johan...@sipsolutions.net> 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
tools.
... 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.
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/
