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