linux-kernel - Re: [RFD] perf: Integrate logging facilities

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] [day] [month] [year] [list]

Message-ID: <4F5E9DFB.40203@lge.com>
Date:	Tue, 13 Mar 2012 10:08:11 +0900
From:	Namhyung Kim <namhyung.kim@....com>
To:	linux-kernel@...r.kernel.org
Cc:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Namhyung Kim <namhyung@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFD] perf: Integrate logging facilities

Hi,

2012-03-13 12:52 AM, David Ahern wrote:
> On 3/12/12 3:58 AM, Namhyung Kim wrote:
>> This is a rough idea and there can be things I am missing. So I need to
>> listen to your advices.
>
> What Arnaldo proposed was having core, library code return error codes and not
> print anything to the user. Higher layers (commands only?) can take the return
> error code and pass it to perf_<subsystem>_strerror() to dump a user friendly
> string for the error. See
>
> http://lkml.org/lkml/2012/2/13/302
>

It will work well for error cases, but how about warnings? I mean the case of 
something like handling new features on old kernels. I want give a (warning) 
message to user but let the code keep going instead of returning to the user. 
It seems not possible on above scenario, so should it be handled at all in 
higher layers? Couldn't the core code have that kind of flexiblity?

And current library code has lots of calls to pr_debug*, dump_printf as well 
as (something-or-)die. How can we handle this? For debugging functions, it 
cannot be moved out of the library for obvious reasons. For die, it can be 
converted to return a error code, but it might require adding non-trivial 
error handling path especially for deeply nested code IMHO.

Also, I think my proposal can still be applied for higher layer codes. It'd be 
better to standardize logging facilities at least for high level in order to 
be flexible for future changes.

Thanks,
Namhyung

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