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

[Ingo Molnar]

* 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
   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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/