linux-kernel - Re: [RFC][PATCH 00/15] tools: Unify perf and trace-cmd trace event format parsing v2

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, 09 Apr 2012 19:13:19 +0900
From:	Namhyung Kim <namhyung.kim@....com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Borislav Petkov <bp@...en8.de>, Jiri Olsa <jolsa@...hat.com>,
	Arun Sharma <asharma@...com>,
	Michael Rubin <mrubin@...gle.com>,
	David Sharp <dhsharp@...gle.com>,
	Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
	Julia Lawall <julia@...u.dk>, Tom Zanussi <tzanussi@...il.com>
Subject: Re: [RFC][PATCH 00/15] tools: Unify perf and trace-cmd trace event format parsing v2

Hi,

On Fri,  6 Apr 2012 00:47:51 +0200, Frederic Weisbecker wrote:
> So I think we really need to restart the debate. We strongly need to make
> progresses in this area so I'm posting this iteration in the hope we
> can move forward. With the coming of uprobes, there are some chances
> that our tracing becomes more important in the future. Let's join
> our efforts.
>

My concern is its error reporting mechanism - being a generic library it
should support various environments like GUI as well as stdio. I see
current warning, pr_stat and die can be overridden via strong symbol
binding but it's just briefly documented and need more explicit handling
IMHO - something like setup/reset_error_functions or so.

In addition, I think we should avoid using die-like functions that can
terminate a client program in the middle of library calls. Instead,
return proper error codes so that the client can handle its failure and
take appropriate actions it needs. Making the library more robust is
also needed of course - please see my other posting today [1].

Thanks,
Namhyung

[1] https://lkml.org/lkml/2012/4/8/177
--
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/