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 78917A04B1; Wed, 23 Sep 2020 14:46:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 07ED91D969; Wed, 23 Sep 2020 14:46:28 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id C172A1D68B for ; Wed, 23 Sep 2020 14:46:25 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 482405C01C9; Wed, 23 Sep 2020 08:46:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 23 Sep 2020 08:46:23 -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= ImAuosuKTIGZJlZPRUolfvdqME2Jkkzige+Re9dqq1g=; b=eCLEndCMt62wqYgT e95zVoJbMesFg9SlZHmUEmEgJdUWTfdfXUOWMwk4TpR0xkgQ7L/050BMGFWSV7Gz r1latmmHxBuYnJn8q09PbBsUKjApFW2jhLNSdAmMruwnahMf96ksnhLDHkGLcUdl f5v8vW2T5cDCkWBU1t1tFERZA54SPgO4zoY2NZNLqx20etn2ebVVn/LzbsAhpUy1 GPqAlqxrLidUH+TaaGydnrGO51O/KUrE4cGlWcvh+B+60vd6Yqk4NVEdC7gCDMYd ugHUDxgqWJ3kkA87F9zo2XoogOq9YJxcgM9G7hZ5ggNZ3iAVpkgSZBMzQTFeGvds EthrmQ== 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=ImAuosuKTIGZJlZPRUolfvdqME2Jkkzige+Re9dqq 1g=; b=mZExqzB5ftNxQqJHOUGIK2nGOk75cZ3NxRxt92R29oxN1qoAfsW3rXRaO 8Sj38nGrDFSo/IKGjpK5qqcwZmBoLEhgPFRQwVPsmYq0qOg1hBU1AebqFAtjCBY0 YNe9CeLnLSJ+zPT1q/U1oL+/KDWI5HNbx1vaeI9neCjjTkHSBLgKed3dwfheJevr tO3JwjAHMUYJTMVgyghDvFf9meIaLbbl/Y+XVDpC0WcdSUVYIo9IPj6FAgXc5VFt wrQnSjLEXhlU/Eyz8rbdySgs0bTZEkUNLo8ksRBqlaskWoNGB7xS+MyUvezrApFF vtUjrVyNUtBGvYcj6lcuB/Y0ah62A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeigdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 2D0A53064682; Wed, 23 Sep 2020 08:46:22 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: Andrew Rybchenko , david.marchand@redhat.com, dev@dpdk.org, ferruh.yigit@intel.com Date: Wed, 23 Sep 2020 14:46:20 +0200 Message-ID: <2369022.OBMSpb71sc@thomas> In-Reply-To: <20200918084136.GD1583@bricha3-MOBL.ger.corp.intel.com> References: <20200916164429.244847-1-bruce.richardson@intel.com> <20200918084136.GD1583@bricha3-MOBL.ger.corp.intel.com> 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" 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.