On Tue, 2 Mar 2021 10:44:14 +0530 Sameeruddin Shaik <sameeruddin.shaik8@xxxxxxxxx> 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
|