hi, >I forgot to include you on the Cc for this email. Not a problem at all steve , bugzilla daemon sent me an update:) I have read your requirements, I am thinking to give 3 incremental patches for this API patch-1 : will write normal strings into the filter file patch-2: will handle the kernel glob expressions patch-3: will handle the regular expressions >I think there should be a complementary API for deleting the filters, >may be something like >int tracefs_function_filter_remove(struct tracefs_instance *instance, > const char * > const *filters, > const char *module) > It should be able to remove the filters, configured by the first API > with the same "filters, module" input parameters. Tzvetomir, Let's wait for the steve inputs on this. Thanks and regards, sameeruddin shaik. On Wed, Feb 24, 2021 at 1:10 PM Tzvetomir Stoyanov <tz.stoyanov@xxxxxxxxx> wrote: > > On Tue, Feb 23, 2021 at 7:07 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > > > Forwarding this to the mailing list, as well. Any discussions on this may > > be easier to discuss here than on the bugzilla. > > > > -- Steve > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=210643 > > > > --- Comment #7 from Steven Rostedt (rostedt@xxxxxxxxxxx) --- > > After some discussions on the mailing lists, I found that it is important to > > establish the requirements that I expect of this API. I'm doing it in the > > bugzilla instead of the mailing list (but will also forward this to the > > mailing list), as this is more about the feature request and not about the > > development of it. > > > > The prototype should be: > > > > int tracefs_function_filter(struct tracefs_instance *instance, > > const char * const *filters, > > const char *module, > > boolean reset); > > I think there should be a complementary API for deleting the filters, > may be something like > int tracefs_function_filter_remove(struct tracefs_instance *instance, > const char * > const *filters, > const char *module) > It should be able to remove the filters, configured by the first API > with the same "filters, module" input parameters. > > > > > If @instance is NULL, the filter for the top level tracing directory is > > used. Otherwise the filter is for the given instance. > > > > The @filters is an array of strings that holds one or more filters, and the > > array ends with a NULL pointer. > > > > If @module is set, only apply the filter to functions for a given module. > > This is ignored if NULL is passed in. I added this to the interface because > > it is commonly used, and the set_ftrace_filter has a special way to handle > > it (see more below). > > > > If @reset is set, the function filter for the given instance (or toplevel if > > @instance is NULL), is cleared before applying the new filter functions. > > Otherwise, the function filters are appended. > > > > Note on reset being set: This is an important implementation detail. The > > reset must be done by opening the file with O_WRONLY|O_TRUNC set. And the > > file is not closed until all the new filters are added. It must not clear > > the file and close it before setting the new filters. The reason is, if it > > does, then all functions will start to be traced! > > > > If the function filter has some functions in set_ftrace_filter, and the > > function tracer is active, then it is only tracing those functions in > > set_ftrace_filter. If you want to change that set of functions to a new set, > > you open the set_ftrace_filter file with O_WRONLY|O_TRUNC and add your new > > functions. On closing the file, the change takes place. The old functions > > being filtered will no longer be traced, and the new functions being filter > > will start to be traced. > > > > If the set_ftrace_filter is truncated and closed without setting the new > > functions, then the function tracer will start tracing *all* functions! > > That is not what this API should do. This is why it is important that you > > write the new filters after opening with O_TRUNC and before closing the > > file descriptor. This is another reason to use an array of filters instead > > of having the application call this function multiple times with different > > filters strings. > > > > Now when writing the filters, the following should be done for each filter. > > Write the filter to set_ftrace_filter file, and if it succeeds, then > > continue to the next filter. If it does not succeed, then check if it is a > > regex. If so, then add all the functions that match the regex that are in > > available_filter_functions. > > > > Note, if @module is not NULL, then before writing the filter strings for the > > non regex write, append ":mod:@module" to each filter string. That is, if > > @module is "bridge" and the filter is "br_*", then what should be written > > into the set_ftrace_filter file is: "br_*:mod:bridge", and the kernel will > > only apply the "br_*" to the module "bridge". Implementation detail, you > > can simply write the filter unmodified, then write ":mod:" then write > > "bridge", before writing any spaces to separate the filters. The kernel > > will process that as one string "br_*:mod:bridge". This way the function > > does not need to worry about allocating extra memory and copying the string > > to append the ":mod:bridge" before writing. > > > > If a regex is used, then the search of available_filter_functions should > > only look for function names that have the module name behind it. That is, > > if @module is "bridge" and the filter is ".*switchdev_\\(port\\|fdb\\).*", > > and @module is set, then the search over available_filter_functions should > > run the regex only on functions that have a matching module name "[bridge]". > > > > -- > > You may reply to this email to add a comment. > > > > You are receiving this mail because: > > You reported the bug. > > You are watching the assignee of the bug. > > You are watching the reporter of the bug. > > > > -- > Tzvetomir (Ceco) Stoyanov > VMware Open Source Technology Center
|