Re: [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros for compatibility

[Thomas Monjalon <thomas@monjalon.net>]

18/09/2020 10:41, Bruce Richardson:
> On Thu, Sep 17, 2020 at 08:59:26PM +0300, Andrew Rybchenko wrote:
> > On 9/16/20 7:44 PM, Bruce Richardson wrote:
> > > * We still have inconsistencies in our driver macro and naming templates.
> > >    This is just a nice-to-have, but if people are ok with generally having a
> > >    breakage in our macro defines, we could clean this up a lot further.
> > >    Notice how 'net', 'regex' and 'vdpa' have '_PMD' at the end, while most
> > >    others have it before the name. Notice also that many device classes have
> > >    the class at the end of the template, while bbdev has it in the middle.
> > > 	$ git grep config_flag_fmt -- drivers/*/meson.build
> > > 	drivers/baseband/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_BBDEV_@0@'
> > > 	drivers/bus/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_BUS'
> > > 	drivers/common/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_COMMON'
> > > 	drivers/compress/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@'
> > > 	drivers/crypto/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@'
> > > 	drivers/event/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_EVENTDEV'
> > > 	drivers/mempool/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_MEMPOOL'
> > > 	drivers/net/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
> > > 	drivers/raw/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_RAWDEV'
> > > 	drivers/regex/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
> > > 	drivers/vdpa/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
> > 
> > As a generic direction I would vote for standard names which are
> > based on directory structure:
> >  - RTE_LIBRTE_ETHDEV
> >  - RTE_DRIVER_NET_SFC
> >  - RTE_DRIVER_COMMON_MLX5
> >  - RTE_DRIVER_BUS_PCI

I would prefer RTE_LIB_ETHDEV (instead of LIBRTE).
If we plan to rework all flags, I would even prefer
	- DPDK_LIB_ETHDEV
	- DPDK_DRIVER_BUS_PCI

> Definite +1, and it would be good if we standardized the .so names like
> that too.

+1 to align .so names for clarity.

> The open question is how much backward compatibility needs to be maintained
> for macros (and also too for .so names)? With this patchset, I've aimed
> very much to keep strict compatibility for now.

As David said, the compatibility is mostly for apps using driver-specific API.
We could also consider that the compatibility break was announced
as part of the makefile removal.
In any case, it is not ABI sensitive, so no need to wait 21.11.
If choosing between a compilation flag breakage in 21.02 or 20.11,
I would prefer 20.11 where legacy build system is removed.

About LTS, we may want to have some patches targetted to 18.11 and 19.11,
to allow a transparent switch between make and meson.