2017-02-06 14:29, Olivier Matz: > The objective of this RFC patchset is to introduce a framework to > support dynamic log types in EAL. It also provides one example of use > (in i40e). > > Features: > - log types are identified by a string > - at registration, a uniq identifier is associated to a log type > - each log type can have its level changed dynamically > - extend command line parameters to set the log level of a specific > type, or logs matching a regular expression > - keep compat with other legacy types (eal, malloc, ring, user*, > etc... keep their hardcoded log type value) > > At the end, when, we can expect that all non-dataplane logs are moved to > be dynamic, so we can enable/disable them at runtime, without > recompiling. Many debug options can probably be removed from > configuration: > $ git grep DEBUG config/common_base | wc -l > 89
I think it would be a very nice cleanup and usability improvement. It seems that everybody agrees that dynamic logging config is better. There were 2 comments that I want to sum up here: 1/ Why not use an external log library? It is not obvious that there is a real benefit to use another system. And Olivier already wrote the code for this system. If someone writes the integration of another log system, we could consider it. 2/ Why filtering by log type instead of file/function? File/function filtering targets DPDK debug use cases. For application developers or system integrators, the log type seems a good level of abstraction for logging part of the system. Anyway, the file/function filtering could be added later if someone integrates it in the dynamic logging configuration system. The conclusion is that this series seems good to integrate. As it is a RFC, do you plan to send a refresh or can we merge it as is?
