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 667F1A056A; Wed, 10 Mar 2021 22:25:02 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 000CC22A4BF; Wed, 10 Mar 2021 22:25:01 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 7514540F35 for ; Wed, 10 Mar 2021 22:25:00 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 824BB20B3754; Wed, 10 Mar 2021 13:24:59 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 824BB20B3754 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1615411499; bh=E/YE9rxW++JIbpLivsH2thhyV4oJgBFdQx6O1NPKIBg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iiyE8ZQx37jzIUxiOQCU4AUIo1uPKrKPWrXrnvP8eFgkPrL/ycZMPvI+ar4nXK/GC LnurLtzW4a9rmMug8pLubhdK2kM+ly0Gp09Nz0aYnilV2CMyEgRJnM2tklhYc8y7uv 0c6Jc+/1swXOA44IlRLEoDvR7hBJ7sx+TQcxKFpo= Date: Wed, 10 Mar 2021 13:24:59 -0800 From: Tyler Retzlaff To: Thomas Monjalon Cc: dev@dpdk.org, bruce.richardson@intel.com, olivier.matz@6wind.com Message-ID: <20210310212459.GA29939@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20210212190936.GA2579@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <4724511.8By67KtOdl@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4724511.8By67KtOdl@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dpdk-dev] officially support building driver plugins externally 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 Wed, Mar 10, 2021 at 09:52:58PM +0100, Thomas Monjalon wrote: > 12/02/2021 20:09, Tyler Retzlaff: > > Recently installation of driver headers and export of functions was pulled back from being public to private (commit df96fd0d73955bdc7ca3909e772ff2ad903249c6). From a discussion with Thomas Monjalon we understand that it was not the design intent to ever have these headers exposed publicly, but it was allowing us to maintain the drivers we do implement outside of the normal dpdk tree. > > > > We would like to propose that building driver plugins external to the dpdk source tree be officially supported / restored and it is is our understanding there there are asks from other DPDK consumers for the same. We understand the main concern is that it might incorrectly convey that the API/ABI of the driver interface is stable or promised to be compatible when no such promise exists. sorry for previous mail format i didn't intend for things to be hard to read. > > Yes we must have a clean API export for application. > The driver interface should not be exported by default. agreed for both points. i think introducing another name to the set of __rte_internal, __rte_experimental, __rte_ is probably the mechanism to use? > > > Can the broader community help us with an acceptable solution to building the drivers out of the tree? Aside from installing the needed headers what other mechanical things can we do to achieve this? We are happy to do the work/submit the required patches as necessary. > > What about a meson option to export the driver interface files? i would propose driver interface files installation defaults to off and a meson option -D=true has to be passed to enable installation. > Should it be exported in the same include directory as API files? that is a good question, i'm not sure there is substantial value if we are defaulting to not installing the driver interface files. but i have no objection if someone sees value in a deeper include path. > Should it be accessible with a pkg-config file? i haven't worked with pkg-config in some time, is the suggestion that we include a .pc file or something so a dependent/external driver can detect that the driver interface files are available? my first thought is no because it is an unstable api i would not want to encourage automatically finding and depending on the driver interface and instead opt for external drivers to have to jump through a few hoops. but perhaps you have other ideas in mind?