Messages in this thread | | | Date | Mon, 29 Sep 2008 11:11:15 +0200 | From | "Frédéric Weisbecker" <> | Subject | Re: [Path -tip 1/3] Tracing/ftrace: Change the type of the print_line callback |
| |
2008/9/28 Pekka Paalanen <pq@iki.fi>: > I might have chosen names like TRACE_PRINT_{RETRY,DONE,DEFAULT_FORMAT}, > but it's your call. I'm not sure which one is more self-explanatory > when you see a "return TRACE_...;" or "if (ret == TRACE_...)"
Hmm yes that's perhaps more explicit.
> Shouldn't the return type be bool? > If it's not, reading this function makes me wonder about the conversion > from enum to int, i.e. what is the meaning of the int.
Actually it should be enum print_line_t. I forgot to change its type. But we need to check its return value as an enum print_line_t.
> It would be shorter to write > if (ret != TRACE_TYPE_UNHANDLED) > and then one could even > return (ret == TRACE_TYPE_HANDLED);
Yes, I corrected it in my "week-end patch" :-)
> Do these actually need checking? I don't think > the default print functions would ever return > TRACE_TYPE_UNHANDLED, could they? > And even if they did, do all the different default print > functions not handle the same set of entry types?
At this moment they don't. But I just wanted to set a security in case of possible future changes in these functions.
> We have to find a proper way to prevent the pipe from closing > early. I'm trying to look into this. I'd like you to leave > that last hunk out. Other than that, very good.
I made a new patch this week-end and I found a way to prevent from closing the pipe. I will just change a bit my patch in the base of your comments.
> btw. there might be a corner case, when a single line does not > fit even into an empty struct trace_seq in tracing_read_pipe(), > but I haven't thought of that yet. I'd expect it to hang.
I should look at this possible issue too. I didn't think about it yet.
| |