Re: [Path -tip 1/3] Tracing/ftrace: Change the type of the print_line callback

["Frédéric Weisbecker" <fweisbec@gmail.com>]

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.