lkml.org 
[lkml]   [2014]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFD] perf syscall error handling

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

> Hi,
>
> On Fri, Oct 31, 2014 at 1:28 PM, Matt Fleming <matt@console-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


\
 
 \ /
  Last update: 2014-11-10 12:01    [W:0.104 / U:5.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site