From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Matz Subject: Re: [RFC 0/8] eal: dynamic logs Date: Fri, 17 Mar 2017 16:32:33 +0100 Message-ID: <20170317163233.082250d7@platinum> References: <1486387756-16865-1-git-send-email-olivier.matz@6wind.com> <6135132.unKH2kKz59@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Thomas Monjalon Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 8F1F469EC for ; Fri, 17 Mar 2017 16:32:36 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id t189so18895126wmt.1 for ; Fri, 17 Mar 2017 08:32:36 -0700 (PDT) In-Reply-To: <6135132.unKH2kKz59@xps13> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Thomas, On Wed, 15 Mar 2017 17:35:32 +0100, Thomas Monjalon wrote: > 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? I'll send a refresh, the patchset does not apply on current master. Regards, Olivier