On Tue, 10 Dec 2013 14:30:18 +0900, Namhyung Kim wrote: > On Tue, 10 Dec 2013 14:01:44 +0900, Namhyung Kim wrote: >> On Mon, 9 Dec 2013 21:14:10 -0500, Steven Rostedt wrote: >>> On Tue, 10 Dec 2013 11:03:44 +0900 >>> Namhyung Kim <namhy...@kernel.org> wrote: >>> >>>> What about returning error code rather than string? This way we won't >>>> worry about the allocation of the error string itself. >>>> >>>> But the downside of it is loosing a positional info of the error. >>>> Hmm.. what about using a static buffer in pevent for it then? >>> >>> A static buffer may be the solution. Never need to worry about >>> allocating it on error, as it will already be allocated. And we can add >>> APIs to print it nicely. >>> >>> Perhaps call it >>> >>> pevent->filter_error_buffer >>> >>> ? > > Hmm.. thinking about it twice, if it's only for filter functions > wouldn't it be better moving it to event_filter rather than pevent? > > filter->error_buffer >
One more thinking, if we agree on converting to return error code, does pevent_filter_add_filter_str() also need to be changed not to receive the third "error_str" argument? And should we extend the error code to include the return value of pevent_filter_match() too? If not, it seems we need to pass another argument to receive the actual error code in case of FILTER_ERROR. I'm saying these here since they might require interface/signature change so will affect existing users like trace-cmd. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
