Re: [dpdk-stable] [EXT] Re: [dpdk-dev] [PATCH v2 01/13] security: fix verification of parameters

[Thomas Monjalon <thomas@monjalon.net>]

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)