lkml.org 
[lkml]   [2013]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 7/9] perf util: Get rid of read_or_die() in trace-event-read.c
From
Date
On Wed, 2013-03-20 at 10:24 +0900, Namhyung Kim wrote:

> >> @@ -61,8 +61,10 @@ static int do_read(int fd, void *buf, int size)
> >> if (repipe) {
> >> int retw = write(STDOUT_FILENO, buf, ret);
> >>
> >> - if (retw <= 0 || retw != ret)
> >> - die("repiping input file");
> >> + if (retw <= 0 || retw != ret) {
> >> + pr_debug("repiping input file");
> >
> > Again, why debug and not err?
>
> Well, there's a pr_err() at the caller of top-level trace_report() in
> case of error. So if we use pr_err() there'll be multiple error message
> for one failure and I don't think it's so helpful to normal users. If
> one really wants to know what happens inside, she will set -v to see
> this low-level debug message.
>
> Does that make sense?
>

I haven't looked at the context of all the changes as to where they are
called from. I'm fine if we have a methodology of having pr_err() at the
top level and pr_debug() within the nested code. It looked to me that
the choices were somewhat random, but then again, I was missing context
to the code.

As long as a pr_err() that gives the user enough information to know
what went wrong is displayed, I'm fine with other errors using
pr_debug().

-- Steve




\
 
 \ /
  Last update: 2013-03-20 03:41    [W:0.038 / U:1.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site