From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=yvMuO6aiIYB/LFbbDlgZVsCXsf9wHTT9iP5siK6tedQ=; b=zP7neFHB76Z3gayYfBnCqJwEVKV14QqERH+zU3T5wTHESBbFXYC+CbukF/APEAt1Nd uO2qSFoOPr0w0SX2pMKPXuDyzhaGjiNUqBKL6MAR9FpLemu8mjxqxlQsljVXGyjVcPqq eiefGlKId1hvXXbpnS14gmGgrf3A+8tTrnPQ8OMmSIHg6EIyW7U5LXWrlzffREzCPgzp zQrnI1avn2XbhhWUXTnha1Z1pCtJfb8kFQsiCIOG07eUVBognI1acZUL2rMzszaNGV5N Y6Ln9OjBbXsrWJo17Y1wnmLLPQA3v+rD0hSntbdKjpDW0RiP069hZO2dr0cFeYulzLlm B3CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=yvMuO6aiIYB/LFbbDlgZVsCXsf9wHTT9iP5siK6tedQ=; b=P8IPm/ImD5fuO2AgG+rjUVt7poEZo3f3wtsvJcvCyhhaJkj1RGwVe0wXzN/ZaPDUrh qTeg74bo2Y0zYYrWzoFzs5hqSJ9TVF+k+/OodaDOIeRkQla4mpByQBuC/dKNr4slZDCD 3/cyTdkBUfm6O7avUB41gte5RUm6mxmn5weqV8JKYnnRYGf2u7W9yIJJdO2IvU7shA1l a4nZP+g6pcTp9h+SDIsg8UgaVH6eqBuqbIPI8Tlvue22PlSESz+A7x2YSfW/nnywn3fj Rl1qqddbaNmhG2+sT2qPBmLTuddCtdkT/6hgwqa7qfMrvZZgKcw3mPMAb2oc0W+ClrH/ jubw== X-Gm-Message-State: AFeK/H2DkENJCStFcOZ96rmhEPAjIkMNk+Wxldr80XQgYx7JrmKicTVz2bHCC/D+kVYPOwrf X-Received: by 10.223.164.16 with SMTP id d16mr3700031wra.47.1489595734230; Wed, 15 Mar 2017 09:35:34 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id c8sm2959088wrd.34.2017.03.15.09.35.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 09:35:33 -0700 (PDT) From: Thomas Monjalon To: Olivier Matz Cc: dev@dpdk.org Date: Wed, 15 Mar 2017 17:35:32 +0100 Message-ID: <6135132.unKH2kKz59@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1486387756-16865-1-git-send-email-olivier.matz@6wind.com> References: <1486387756-16865-1-git-send-email-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC 0/8] eal: dynamic logs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:35:34 -0000 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?