From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 49EECA0598 for ; Thu, 9 Apr 2020 12:54:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2FEDE1C240; Thu, 9 Apr 2020 12:54:19 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 9F35A1C22A; Thu, 9 Apr 2020 12:54:16 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 3414E58058A; Thu, 9 Apr 2020 06:54:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 09 Apr 2020 06:54:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=clfUIlNuKNZtVc4d9KOf/CPLzNs8HE0L7j5GCIUz8GE=; b=LtYwjBmwV7rV y0T6NMQkrltqz+pDd7E/TFymF0cY9QlWBZR3PDQ/rN1ibRXD2miTLDdYJF/DyZWg +tVN6Rt+CHGeH2Kqg9T6WAoc5w640w/RxoNEguBGwFrDl0hkEJlrXaGXPvvBQqLp TLmtv9Euh1yXu7YzHhEt+0sbvos7xjA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=clfUIlNuKNZtVc4d9KOf/CPLzNs8HE0L7j5GCIUz8 GE=; b=utnFZHt/emkyp3N33j9vUn1eThXQ4S4QLRXDyoVMNL/o6eE8UmKWIN5eT FIqWFO82lhJIihz05p2XmBpnrjEz5yXw+sHB/Z1REAJIXdF4arGC6dG4d14ij/MR lBcLekNFY82wwsnrKrT7f4+abkED9xRgkDlPeHTVyBnh+HfU9J57KKJqKFltq5z6 uZ2LvYmgTeTQ3+GhKyNzQpgWunjzmr6CS5QIjO1Zcp+efaL6F9+/wFQ8Oz7UBAKL PPAFbngi8L0ErY5MMeLpy43h4lVE/ku1b6zJLLchPzhEYHyuGbiDMQP9BLelg++a bV5HmYYYM3DsPYTkopnPaqAbtEu2w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 19EDB3280069; Thu, 9 Apr 2020 06:54:12 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: Lukasz Wojciechowski , Anoob Joseph , Akhil Goyal , Declan Doherty , Aviad Yehezkel , Boris Pismenny , Radu Nicolau , Anoob Joseph , "dev@dpdk.org" , "stable@dpdk.org" Date: Thu, 09 Apr 2020 12:54:10 +0200 Message-ID: <22404743.ouqheUzb2q@thomas> In-Reply-To: <20200409101445.GA613@bricha3-MOBL.ger.corp.intel.com> References: <20200312151654.7218-1-l.wojciechow@partner.samsung.com> <2333397.jE0xQCEvom@thomas> <20200409101445.GA613@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [EXT] Re: [dpdk-dev] [PATCH v2 01/13] security: fix verification of parameters X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 09/04/2020 12:14, Bruce Richardson: > On Wed, Apr 08, 2020 at 07:51:35PM +0200, Thomas Monjalon wrote: > > 08/04/2020 17:49, Lukasz Wojciechowski: > > > Hi guys, > > > > > > I don't know what is the current status of "legacy" build using > > > gnumakes, so I added the new DEBUG flag to config just as it was done in > > > other libs like eventdev. > > > Many guides still point config files as the one that should be changed > > > in order to enable some features, so I thought I should add it there. > > > > > > If I understand well the official build system now is the one based on > > > using meson and ninja, however it hasn't got anything similar to the > > > gnamakefiles system, e.g. > > > in the meson.build file for libraries all the libraries have build > > > variable set to true and there are few ifs that check it, but as it's > > > set to true all libraries build always. > > > And each library considered there defines RTE_LIBRTE_[LIBRARY_NAME]. > > > It's kind of weird. > > > > > > foreach l:libraries > > > * build = true** > > > * reason = '' # set if build == false to explain why > > > ... > > > * if not build* > > > dpdk_libs_disabled += name > > > set_variable(name.underscorify() + '_disable_reason', reason) > > > else > > > enabled_libs += name > > > *dpdk_conf.set('RTE_LIBRTE_' + name.to_upper(), 1)* > > > ... > > > > > > Have you think about reusing config files in meson configuration and > > > have a single point of configuration? Of course all meson flags can > > > overwrite the default config. > > > > This is on purpose. > > We are removing most of compile-time options with meson. > > > > I think we can use a global option for debug-specific code. > > Bruce, what do you recommend? > > > Meson has a built-in global debug setting which could be used. However, > that may be too course-grained. If that is the case there are a couple of > options: > > 1 Each library can have it's own debug flag defined, which is set on > the commandline in CFLAGS. Can be done right now - just reuse any of the > debug variables in the existing make config files (stripping off the > CONFIG_), e.g. CFLAGS=-DRTE_MALLOC_DEBUG > 2 Since that is perhaps not the most usable - though easiest to implement - > we can look to add a general debug option (or couple of options) in > meson, e.g. debug_libs=, debug_drivers=, where each option takes a list of > libs or drivers to pass the debug flags to. This will require a little > work in the meson build infrastructure, but is not that hard. The harder > part is standardizing the debug flags across all components. > > The advantage of #1 is that it works today and just needs some > documentation for each lib/driver what it's debug flags are. The advantage > of #2 is more usability, but it requires a lot more work to standardize > IMHO. In this case, we need a general option as the one already provided by meson. It means: "I am not in production, I want to see anything behaving wrong in the datapath." "Anything" means we don't need a per-library switch. And for the other needs (out of fast path), we have a new function: rte_log_can_log(mylogtype, RTE_LOG_DEBUG)