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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Mar 2010 18:50:10 -0300
From:	Arnaldo Carvalho de Melo <acme@...radead.org>
To:	Masami Hiramatsu <mhiramat@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>, lkml <linux-kernel@...r.kernel.org>,
	systemtap <systemtap@...rces.redhat.com>,
	DLE <dle-develop@...ts.sourceforge.net>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Mike Galbraith <efault@....de>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH -tip 5/7] perf probe: Query basic types from debuginfo

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/