From: Masami Hiramatsu <mhiramat@redhat.com>
To: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>, lkml <linux-kernel@vger.kernel.org>,
systemtap <systemtap@sources.redhat.com>,
DLE <dle-develop@lists.sourceforge.net>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <peterz@infradead.org>,
Mike Galbraith <efault@gmx.de>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH -tip 5/7] perf probe: Query basic types from debuginfo
Date: Mon, 29 Mar 2010 18:05:03 -0400 [thread overview]
Message-ID: <4BB1240F.1050300@redhat.com> (raw)
In-Reply-To: <20100329215009.GA2851@ghostprotocols.net>
Arnaldo Carvalho de Melo wrote:
> 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.
Ah, that's very nice:)
OK, I'll try to use it and remove all 'die()'s.
Thank you!
>
> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Masami Hiramatsu
e-mail: mhiramat@redhat.com
next prev parent reply other threads:[~2010-03-29 22:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-29 20:37 [PATCH -tip 0/7] perf-probe updates - data-structure support improvements, etc Masami Hiramatsu
2010-03-29 20:37 ` [PATCH -tip 1/7] [BUGFIX] perf probe: Fix to close dwarf when failing to analyze it Masami Hiramatsu
2010-03-29 20:37 ` [PATCH -tip 2/7] perf probe: Support argument name Masami Hiramatsu
2010-03-29 20:38 ` [PATCH -tip 3/7] perf probe: Use the last field name as the " Masami Hiramatsu
2010-03-29 20:38 ` [PATCH -tip 4/7] trace/kprobes: Support basic types Masami Hiramatsu
2010-03-29 20:38 ` [PATCH -tip 5/7] perf probe: Query basic types from debuginfo Masami Hiramatsu
2010-03-29 20:51 ` Arnaldo Carvalho de Melo
2010-03-29 21:22 ` Masami Hiramatsu
2010-03-29 21:50 ` Arnaldo Carvalho de Melo
2010-03-29 22:05 ` Masami Hiramatsu [this message]
2010-03-29 22:23 ` Arnaldo Carvalho de Melo
2010-03-29 20:38 ` [PATCH -tip 6/7] perf probe: Support basic type casting Masami Hiramatsu
2010-03-29 20:38 ` [PATCH -tip 7/7] perf probe: Support DW_OP_call_frame_cfa in debuginfo Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BB1240F.1050300@redhat.com \
--to=mhiramat@redhat.com \
--cc=acme@infradead.org \
--cc=dle-develop@lists.sourceforge.net \
--cc=efault@gmx.de \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.