From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 93641A0A0A; Mon, 29 Mar 2021 21:31:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BBAFE406B4; Mon, 29 Mar 2021 21:31:38 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 9112E4069D; Mon, 29 Mar 2021 21:31:37 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D2CEC5C0109; Mon, 29 Mar 2021 15:31:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 29 Mar 2021 15:31:35 -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=fm3; bh= 3bxbKFPxjA+4ODLNKyiZ+oX1WK4lXox2c3pg4FujSdc=; b=rpkRQVNzrczUd4OS wrfzuzUC89GGA1mmxCGtLxZJREuNnILm8VxiDyuRTyZhrajxKXK4Tk43DEHDnxBQ dU1+KvCTXrIpc4eIEynbyEpE9wb+znvzZjYhdSGe1v+XNmJomK1pHxSbSCqSlx87 7CxRiO4wiMfEir2Ct3vHYgL/6LIBJkEUv4KfaVnotMiwcq2cR/V8i7sHezyiqXio RcxvMTvupPNjskJqaPNQZRUsdVG0xywovypuU7GKDKvj/LjvYygx0QoKGtMCYnBH tY5wTMD1ZZFJPi3HwRHDFrP9PGnKt5qVa0vH6t6574y+iCc6c9Y0uH6oFXUKgpYg L7NuZg== 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=fm2; bh=3bxbKFPxjA+4ODLNKyiZ+oX1WK4lXox2c3pg4FujS dc=; b=OiXfAMYeT6fzCTJFeRgI2p0Nv1+7F2TPLiI9ZMd4GLy8RN+rmh1jtyBV8 joKafN34MWkDkZbSbIao65pQPQX17CuKd3zvpv4/iJ2ZpcCdtrVR1TMe9iPGCLK2 pJ+2KDv+sRG+WeZYQOGl+mOFSfxFvc+eCRGW4DsAftQyxvPCfWcinJmyHDRGl443 1uC/tKvol972gqPOqGGjk6sszqo7s2VRVP0hx8QvC4370EJe49/yMB7XQClVtQF6 0OsHABj8PMbhV3fGeV1TnX1cNAewXlsLEYKhriGLHfCE7IdqH1M7uvuHUXxBZNqu SRaCx3oodndXyJGE4+1Kuw+JUHQyg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehkedgudegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth 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 C88D9108005C; Mon, 29 Mar 2021 15:31:33 -0400 (EDT) From: Thomas Monjalon To: Tyler Retzlaff , Ferruh Yigit Cc: dev@dpdk.org, andrew.rybchenko@oktetlabs.ru, bruce.richardson@intel.com, Shepard Siegel , David Marchand , techboard@dpdk.org Date: Mon, 29 Mar 2021 21:31:32 +0200 Message-ID: <9106083.eXt1UuAYbc@thomas> In-Reply-To: <1b10aa5b-9747-87f3-bc01-e33d202c7d4c@intel.com> References: <1615490833-23052-1-git-send-email-roretzla@linux.microsoft.com> <7513292.jyfq3xXJVz@thomas> <1b10aa5b-9747-87f3-bc01-e33d202c7d4c@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] ethdev: introduce enable_driver_sdk to install driver headers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 29/03/2021 17:23, Ferruh Yigit: > On 3/29/2021 1:10 PM, Thomas Monjalon wrote: > > 29/03/2021 11:43, Ferruh Yigit: > >> On 3/26/2021 8:52 PM, Tyler Retzlaff wrote: > >>> On Fri, Mar 26, 2021 at 12:02:55PM +0000, Ferruh Yigit wrote: > >>>> On 3/24/2021 4:24 PM, Tyler Retzlaff wrote: > >>>>> On Wed, Mar 24, 2021 at 12:30:36PM +0100, Thomas Monjalon wrote: > >>>>>> 24/03/2021 12:27, Ferruh Yigit: > >>>>>>> > >>>>>>> But not sure how to manage the same problem for whole project, if install all > >>>>>>> headers in one patch, or add them gradually via separate patches by time ... > >>>>>> > >>>>>> We did a cleanup in ethdev but not in other driver classes. > >>>>>> When the cleanup will be done gradually, the headers > >>>>>> must move in this new category driver_sdk_headers. > >>>>> > >>>>> yes, some headers are not installed now. so they need only to have > >>>>> their api marked __rte_internal and installed (since there should be no > >>>>> external consumer as a function of not being installed) > >>>>> > >>>>> the more difficult case is where headers were installed but the api were > >>>>> not marked __rte_internal and appear in the stable version.map. for > >>>>> those i guess deprecation notice has to be issued before marking as > >>>>> internal. > >>>>> > >>>> > >>>> Are you referring to any specific APIs, can you share list of them? > >>> > >>> i can't remember the whole list but Thomas originally indicated the > >>> following candidate list. > >>> > >>> baseband/ -> librte_bbdev/rte_bbdev_pmd.h > >>> bus/ -> rte_bus.h > >>> common/ -> no interface > >>> crypto/ -> librte_cryptodev/rte_cryptodev_pmd.h > >>> event/ -> librte_eventdev/ > >>> mempool/ -> librte_mempool/ > >>> net/ -> librte_ethdev/ > >>> raw/ -> librte_rawdev/rte_rawdev_pmd.h > >>> regex/ -> librte_regexdev/rte_regexdev_driver.h > >>> vdpa/ -> librte_vhost/rte_vdpa_dev.h > >>> > >>> some of these headers are not published, some are. > >>> > >> > >> These are public headers, so they should not have '__rte_internal' functions, > >> are you saying some of public headers has internal functions that are presented > >> as public APIs? > > > > These are the headers for use by the drivers. > > We should classify them as SDK headers, not API. > > > > Yes, you are right, they shouldn't be public header. > > So, agree to Tyler's comment, that some of those functions needs to be removed > from the stable API list first, which will take time. > > I can proceed with the ethdev one, any objection? +1 > And for the rest of the list, how can we fix them? I guess best option is to > distribute the work to each library, but we need an owner of the task to follow > and communicate it. +1 +Cc techboard