Re: [PATCH -tip 5/7] perf probe: Query basic types from debuginfo

[Arnaldo Carvalho de Melo]

Em Mon, Mar 29, 2010 at 05:22:00PM -0400, Masami Hiramatsu escreveu:
> Arnaldo Carvalho de Melo wrote:
> > Em Mon, Mar 29, 2010 at 04:38:29PM -0400, Masami Hiramatsu escreveu:
> > Question, should we use the equivalent to panic'ing the kernel in the
> > userspace bits in tools/?

> > I tend to see all code there as potentially part of a library, i.e. to
> > be callable by some unantecipated new tool or library that would rather
> > receive a return value telling it that the operation can't be performed
> > for some reason so that it can inform the user instead of having the
> > whole tool exit to the command line.
> 
> OK, so that you want to see 
> 
> ret = library_func();
> if (ret < 0)	/* Something wrong happened */
> 	return ret;
> 
> instead of 
> 
> library_func();
> hopefully_executed_next_func();

Exactly. That was my _suggestion_ :-)
 
> > It may well be that some specific operation needs lots of resources but
> > many other don't, panic'c because the one that requires lots of
> > resources can't be performed, bringing down a gui/tui is really nasty.
> 
> Hmm, agreed. But I'd like to have some API for storing dying^H^H^H^H^Herror
> message. (maybe can we use setjump/longjump approach - like try/cache - for die()?)

Can't we do just as we do in the kernel and propagate the error back to
callers? All the way to userspace, that in this case would be the user
instead of an app started by a user?  :-)

Wrt api for storing messages, we have pr_{warning,error,debug}, etc, in
the TUI mode it is even redirected to the bottom line and I plan to have
them get into something browseable if the user wants to see the last pr_
messages.

IOW, just act like you're writing kernel code, that will make it more
likely that people that are used to writing code like that will feel at
ease while hacking tools/.

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