30/09/2020 18:49, Richardson, Bruce: > From: Thomas Monjalon <tho...@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 > > Since everything else in DPDK uses an RTE prefix,
Not everything. The applications and scripts are prefixed with dpdk- > I think it might be sensible to keep that here too: > > * RTE_LIB_ETHDEV > * RTE_PMD_BUS_PCI PMD before BUS looks weird. > * RTE_PMD_NET_IXGBE > * RTE_PMD_CRYPTO_KASUMI > etc. > > > > Definite +1, and it would be good if we standardized the .so names like > > > that too. > > > > +1 to align .so names for clarity. > > > I'd really like this, but need to see the implications for any drivers which > may be multi-function, like QAT which has a single .so file. > > > > 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. > > > > Any more thoughts on this? > Any change to standardize the library names is going to have to be done in > 20.11 if it's to be done at all, since that would be an ABI break. I'd tend > towards only changing the defines for 21.02, but if lots of other things are > changing too, perhaps it's not worthwhile waiting.
