Messages in this thread | | | Subject | Re: [PATCH 7/9] perf util: Get rid of read_or_die() in trace-event-read.c | From | Steven Rostedt <> | Date | Tue, 19 Mar 2013 21:59:01 -0400 |
| |
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
| |