lkml.org 
[lkml]   [2012]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2012-03-13 02:11    [W:0.050 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site