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 F280BA04B5; Wed, 30 Sep 2020 19:31:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C44F71D537; Wed, 30 Sep 2020 19:31:11 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id D86B01D52C for ; Wed, 30 Sep 2020 19:31:09 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 866005C00F8; Wed, 30 Sep 2020 13:31:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 30 Sep 2020 13:31:09 -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=fm2; bh= Gb+jiOH0byD+17z2kznH3K8mEWcDatk9Azjxk8o1F5s=; b=qwKFSRlEsTW2P0c/ rhn0u/pwLfYORWAW6iOZD3d7wu5YITCPdpYEW9klf7o7NPPYfaR6CJ/q+iifg6R7 1uJTiWlwuAa6erUDEHhnviSEg1Xw4Z+YJ/NbqAnV0r4BMs4bfqNLB99wJIlb2qSX aGa/MLm04J/Ti1VqkF6MbbW/JJLjFXu0L4Hkl5yMzBrKtbZdeBp5Owv6Bva4jRpt XUA1fWbPsLsaB34RBLoHxLzm7HujewOsu7ie5TdsjKn/+sAtpeafoETdJOx/LLVY nw1fiwodLYDH1uK42V8j9c0dGKbhlzXre2ui54TbmlUzy0+Uk8hbpmPQ5N5eH8tF BP/+gw== 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=fm3; bh=Gb+jiOH0byD+17z2kznH3K8mEWcDatk9Azjxk8o1F 5s=; b=cQy0coTwCt0acXUHboFInSic2IV2wlVnPgG4K5nnJRIdBYkJIfMrXLmQY sIQbCamhILDDJQN6jVXxokOFnFshEamdwAuxSR6OQhi2AGzjAb04T0+8hlZadTG+ L5FVHnmLvkEFhZmK+o4YL/xDnJ5cWCjyUWOzdGomuY1y+NTk4MTjsGyEu5orWop8 wsspyiE9rr6aEsiE38MljtS/4i/ma1gbPxs68DuubXr45UbopSoD18BgbZoeq6LB QsBcAcL3DL4X0h/Gzco/mwqjyLliBlc1acjS6eHp17YLAzdJJ0kcJKJsVL7+uasX Z/dLJ37ybBj9y4cu6y0b2WLJSRLLw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfedvgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 5F0913280064; Wed, 30 Sep 2020 13:31:08 -0400 (EDT) From: Thomas Monjalon To: "Richardson, Bruce" Cc: Andrew Rybchenko , "david.marchand@redhat.com" , "dev@dpdk.org" , "Yigit, Ferruh" Date: Wed, 30 Sep 2020 19:31:06 +0200 Message-ID: <17101817.Xo8ACCIXZc@thomas> In-Reply-To: References: <20200916164429.244847-1-bruce.richardson@intel.com> <2369022.OBMSpb71sc@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros for compatibility X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 30/09/2020 18:49, Richardson, Bruce: > From: Thomas Monjalon > > 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.