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 07BBCA034F; Mon, 29 Mar 2021 11:43:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 79E5E40151; Mon, 29 Mar 2021 11:43:19 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id B753640042 for ; Mon, 29 Mar 2021 11:43:17 +0200 (CEST) IronPort-SDR: buBpW9z9kkhSZRojzUiXZOKY78TruoDiMQbrZC5h+wd8Hk2apRk8GwDVOvB9jVoxWFFSNQ1/jF IH2AVQ82DUXA== X-IronPort-AV: E=McAfee;i="6000,8403,9937"; a="190980041" X-IronPort-AV: E=Sophos;i="5.81,287,1610438400"; d="scan'208";a="190980041" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2021 02:43:14 -0700 IronPort-SDR: EK1rKdlx5SJP7WpV8MkejWvXO3KpILY84aEOltA2IJu5N5mJ3MWZCKkvq/fvFHJGExA72Nd+w1 NIRuLqy/Zlpw== X-IronPort-AV: E=Sophos;i="5.81,287,1610438400"; d="scan'208";a="444481426" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.213.51]) ([10.213.213.51]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2021 02:43:12 -0700 To: Tyler Retzlaff Cc: Thomas Monjalon , dev@dpdk.org, andrew.rybchenko@oktetlabs.ru, bruce.richardson@intel.com, Shepard Siegel , David Marchand References: <1615490833-23052-1-git-send-email-roretzla@linux.microsoft.com> <20210324043238.GA31805@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <7e48bf43-5bee-045e-aef2-f56dc72d8736@intel.com> <5945384.p3lA8Brad8@thomas> <20210324162441.GA14991@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20210326205216.GA4066@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: Ferruh Yigit X-User: ferruhy Message-ID: <0d7346c6-09fb-60ca-e3e5-ac63717fbddb@intel.com> Date: Mon, 29 Mar 2021 10:43:09 +0100 MIME-Version: 1.0 In-Reply-To: <20210326205216.GA4066@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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" 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?