Thanks Jerin for this new version. New round of comments.
- What do you think of splitting the API in two headers, thinking about who will use them? * rte_trace.h (rte_trace_ prefix for all functions/macros/types) for users of the trace framework that want to * get the status of the whole trace subsystem, * enable/disable tracepoints by pattern/regexp, * dump the current events, * rte_tracepoint.h (rte_tracepoint_ prefix for all functions/macros/types) for developers that want to add tracepoints to their code - Having functions "is_disabled" has little value when a "is_enabled" counterpart exists. - What is the value of having a _public_ rte_trace_is_invalid() ? A final user would need to lookup by name to get a trace descriptor and we should hope that such a lookup returns a valid descriptor :-). A developer would already have the descriptor hook point in his own code: by construction, if the tracepoint is registered, then the descriptor is valid, else, it is unknown. - I did not get why we put the trace descriptors in a specific elf section, can you explain the benefits? - I can see no protection on the tracepoint list. Could we have issues with control/application threads that dpdk does not control, dynamic loading of libraries.. ? - Following comment on v4 and the removal of the mode per tracepoint api, don't we need to put the current select mode in each tracepoint descriptor when registering a trace point ? -- David Marchand
