From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [RFC 0/8] eal: dynamic logs Date: Wed, 15 Mar 2017 17:35:32 +0100 Message-ID: <6135132.unKH2kKz59@xps13> References: <1486387756-16865-1-git-send-email-olivier.matz@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Olivier Matz Return-path: Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com [209.85.128.173]) by dpdk.org (Postfix) with ESMTP id 90260201 for ; Wed, 15 Mar 2017 17:35:34 +0100 (CET) Received: by mail-wr0-f173.google.com with SMTP id l37so14796884wrc.1 for ; Wed, 15 Mar 2017 09:35:34 -0700 (PDT) In-Reply-To: <1486387756-16865-1-git-send-email-olivier.matz@6wind.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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?