Message-ID: <20141110103834.GB19309@gmail.com>
Date:	Mon, 10 Nov 2014 11:38:34 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Matt Fleming <matt@...sole-pimps.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Vince Weaver <vince@...ter.net>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFD] perf syscall error handling


* Stephane Eranian <eranian@...gle.com> wrote:

> Hi,
> 
> On Fri, Oct 31, 2014 at 1:28 PM, Matt Fleming <matt@...sole-pimps.org> wrote:
> > On Fri, 31 Oct, at 10:27:13AM, Ingo Molnar wrote:
> >>
> >>  - user-space gets back the regular errno (-EOPNOTSUPP or -ENOSYS
> >>    or -EINVAL, etc.) and a string. Strings are really the most
> >>    helpful information, because tools can just print that. They
> >>    can also match on specific strings and programmatically react
> >>    to them if they want to: we can promise to not arbitrarily
> >>    change error strings once they are introduced. (but even if
> >>    they change, user-space can still print them out.)
> >
> > I guess we'd run into a problem if userspace doesn't want to just print
> > the kernel string but instead wants to parse it in some fashion.
> >
> > That may or may not be a problem in practice, Vince can probably comment
> > on that. I'm just thinking along the lines of making the perf syscall
> > interface as useful as possible for tools other than tools/perf.
>
> Maybe I missed something in the earlier thread, but I am trying 
> to understand why perf_event_open() would need such extended 
> error retrieval system when no other syscall does.

Frankly, Linux kind of sucks in the 'error codes and diagnostics' 
area, as we used the old Unix method of returning a single small 
integer and never got around further organizing errors properly, 
for a couple of good (and a handful of bad) reasons.

The good reasons: not having finegrained error codes is just fine 
if you organize your APIs and objects via other means: file 
system structure, split-up system calls, separate fds for 
separate objects, etc.

The perf ABI is complex mostly because it provides bleeding edge 
interfaces to bleeding edge hardware, while trying to be 
transparent to the probed processes: i.e. no 'everything is a 
file' and 'just use poll() to pass events' API simplifications 
are possible, mostly for performance reasons.

A comparable ABI, ptrace, is considered complex as well, while 
perf is much faster, exposes much more hardware capabilities and 
is more capable as well.

But even outside of perf, with 'other' system calls I have 
experienced dozens of incidents where some app failed with a 
-EINVAL in an ambiguous way and it would have been a blessing to 
get more extended error description from the kernel. There's a 
few meaningful error codes like -EIO or -ENOMEM, but there's tons 
of overlapping use of -EINVAL.

The VFS and VM error codes are pretty much self explanatory (and 
that's where we have most of Unix heritage), but for example the 
networking code and various drivers and also perf suffers from 
not giving finegrained enough error explanations.

> In any case, I would go with Ingo's proposal.

Ok, cool!

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists