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
Em Mon, Nov 10, 2014 at 01:24:47PM +0100, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > Em Mon, Nov 10, 2014 at 11:27:25AM +0100, Ingo Molnar escreveu:
> > > * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > > > Em Mon, Nov 03, 2014 at 05:50:19PM +0100, Peter Zijlstra escreveu:
> > > > > OK, so how about we do both, the offset+mask for the tools
> > > > > and the string for the humans?

It looks like machines don't have problems with strings 8-)

> > > > Yeah, tooling tries to provide the best it can with the
> > > > offset+mask, and if doesn't manage to do anything smart with
> > > > it, just show the string and hope that helps the user to figure
> > > > out what is happening.

> > > Almost: tooling should generally always consider the string as
> > > well, for the (not so uncommon) case where there can be multiple
> > > problems with the same field.

> > > Really, I think the string will give the most bang for the buck,
> > > because it's really simple and straightforward on the kernel side
> > > (so that we have a good chance of achieving full coverage
> > > relatively quickly), and later on we could still complicate it
> > > all with offset+mask if there's really a need.

> > > So lets start with an error string...

> > I don't have a problem with the order of introduction of new
> > error reporting mechanisms, or at least I can't think of one
> > right now.

> > So if we introduce strings now then tools/perf/ will trow them
> > to the user when it still don't have fallbacks or any other UI
> > indication of such an error.

> > I wonder tho if we have any previous experience on some other
> > project (or even in the kernel?) and how userspace ended up
> > using it, if just presenting those strings to the user or if
> > trying to parse it, etc, anybody?

> I'm not aware of any such efforts in the Linux space - subsystems
> with administrative interfaces generally just tend to printk() a
> reason - that's obviously suboptimal in several ways.

> Programmatic use in user-spaec is very simple - go with my
> initial example, tooling can either just display the error string
> and bail out, or do:

> if (unlikely(error)) {
> if (!strcmp(attr->error_str, "x86/bts: BTS not supported by this CPU architecture")) {
> fprintf(stderr, "x86/BTS: No hardware support falling back to branch sampling\n");
> activate_x86_bts_fallback_code();
> goto out;
> }
> if (!strcmp(attr->error_str, "x86/lbr: LBR not supported by this CPU architecture"))
> goto out_err;
> }

> or it may do any number of other things, such as convert it to
> its internal error code. Note that the error messages should have
> some minimal structure (the 'x86/bts:' and 'x86/lbr' prefixes) to
> organize things nicely and to make string clashes less likely.

Right, focus on the string format: Can we just have this two level
thing, first part separated by a slash, followed by colon, to identify
the origin of the message, and then a message, that can have further,
unspecified at this time, parser tokens as the need arises?

> as this is a slowpath the performance of strcmp() doesn't matter,
> and in any case it's hardware accelerated or optimized well on
> most platforms.

- Arnaldo


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