Re: [PATCH] libtracefs: An API to set the filtering of functions

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 2 Mar 2021 10:44:14 +0530
Sameeruddin Shaik <sameeruddin.shaik8@gmail.com> wrote:

> > Let's fix the number of parameters to this function:)  
> 
> >> Not sure what you mean by that.  
> Actually i meant this ""int tracefs_function_filter(struct
> tracefs_instance *instance,
>                                     const char * const * filters,
>                                     const char * module, bool reset,
>                                     const char * const ** errs);""
> For every patch, a parameter is increasing in this API.

And that's a normal approach to developing APIs. I've been doing this
for over 25 years, there's nothing special about this case. In
discussion on APIs, parameters grow to handle new cases. That's par for
the course. There's only 5 parameters, not too many.

> 
> > let's return the number of bytes written, also we will calculate the
> > complete filters length and return it, if there is difference,
> > we will loop into the integer array and print the erroneous filters  
> 
> >>Not sure how that is helpful. How would you use the number of bytes
> >>written?  
> 
> We will return the number of bytes written and we also store the total
> length of strings
> in filters array, in one pointer variable, we will check the
> difference between bytes written
> and the total length of the strings, if there is difference we will
> print failed filters otherwise
> we will not print anything.

Please show an example of a use case that you would use this with?

I gave you an example of how I intend on using it, and the user of this
interface should not care about number of bytes written. And the
interface should not be printing any error messages, it is a library,
error messages are for applications to produce. The interface must give
the application enough information to be able to produce it.


> 
> >It is very useful to have a way to report back the failed filters.
> >Using an array
> >of strings will work for this API, but I was thinking somehow to leverage the
> >error_log file by the ftrace itself. Currently it does not report any
> >error, just
> >returns EINVAL. In more complex filters it would be useful to log
> >more detailed description of the problem in the error_log file.  
> 
> This error_log is also a good idea.

It's actually not very useful for this interface. The only error that
it would give you is that it could not find any functions that match a
filter.

When we create other interfaces that do more than just setting
functions (like setting triggers) then we can return to looking at the
error log. But since the kernel does not produce anything in the error
log at the moment, it must be updated. And kernels take about a year or
two after a change to get into distributions. That means, this library
can't rely on it being there, and still needs a way to inform the
application of errors.

> 
> If possible let's have a live discussion on this API,so that we can
> discuss the corner cases in the design
> more efficiently and we can close it ASAP.
> 

I have a very good idea of what I want from this interface, which is
why I created the bugzilla about it. If you want to implement it
different than my idea, please show code examples of your use cases.

-- Steve