From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 49EECA0598
for <public@inbox.dpdk.org>; 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: <xms:1f6OXnFMZaeVyw_3-QddPU02yqSjUFi5AaCIgxeR97BV8oUrVUW0tQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelgddvlecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph
epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr
rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:1f6OXhfPEPQLSzggEdJ4BNmuXXuKs4dV1xAjitEpRtGGb_AWtWEj0w>
<xmx:1f6OXoIwZ-S-jqnyv12jqNu2dUaWp0YHzd0gvwdrEYopTOIR_f8U5A>
<xmx:1f6OXmG7lb_gXoSLE0i0U053fW0b8ilBdVYYPog4fcxbf3qeV_9tTg>
<xmx:2P6OXskQ471I7SDwmJfsdWzefsya1YEp5UcT0WHukwswrw4YizWuGA>
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 <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>,
Anoob Joseph <anoobj@marvell.com>, Akhil Goyal <akhil.goyal@nxp.com>,
Declan Doherty <declan.doherty@intel.com>,
Aviad Yehezkel <aviadye@mellanox.com>, Boris Pismenny <borisp@mellanox.com>,
Radu Nicolau <radu.nicolau@intel.com>,
Anoob Joseph <anoob.joseph@caviumnetworks.com>, "dev@dpdk.org" <dev@dpdk.org>,
"stable@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 <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
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 = '<unknown 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)