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

[Johannes Berg]

On Wed, 2015-08-26 at 09:20 +0200, Ingo Molnar wrote:
> > 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.

I was considering, at least in this case, to forgo the string entirely 
- that makes it use less space in the kernel (no need for all those
strings) and completely avoids the discussion about translation etc.,
while still being entirely sufficient for the debugging I have in mind.

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

As I'm saying, netlink is that in a way as well :) Except it's not a
syscall per se, since it's layered behind a message passing interface.

> 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.)
> 

Well, if the apps were to be extended trivially to print, in the
netlink case, the attribute with an error, that'd help debugging
significantly - not much need for a string in that case.

But I'll agree that it's a more special case than the perf case you're
looking at where you have things like "your hardware doesn't support
this" which obviously isn't really tied to some argument directly.

johannes
--
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/