From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hemant Agrawal Subject: Re: [PATCHv7 03/47] common/dpaa2: adding qbman driver Date: Wed, 1 Mar 2017 17:56:45 +0530 Message-ID: References: <23fc7ab5-1d1b-183e-7997-6e078d49a499@intel.com> <1662518.dF45MxJRnv@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: , Ferruh Yigit , To: Thomas Monjalon , Shreyansh Jain Return-path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0075.outbound.protection.outlook.com [104.47.36.75]) by dpdk.org (Postfix) with ESMTP id C61BC952 for ; Wed, 1 Mar 2017 13:26:54 +0100 (CET) In-Reply-To: <1662518.dF45MxJRnv@xps13> 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/1/2017 4:30 PM, Thomas Monjalon wrote: > 2017-02-28 05:27, Shreyansh Jain: >> From: Ferruh Yigit >>> On 2/27/2017 10:01 AM, Shreyansh Jain wrote: >>>> On Friday 24 February 2017 03:28 PM, Ferruh Yigit wrote: >>>>> We can go with option (1) now, since these are not real APIs to user >>>>> application, it can be possible to change them if better solution found. >>>>> >>>>> Do you think is it good idea to have different naming syntax for those >>>>> libraries to clarify they are for PMD internal usage? >>>>> >>>> >>>> Indeed. Current name is librte_common_dpaa2_*. >>>> Do you think librte_drvlib_dpaa2 or librte_drvlib_dpaa2_pmd is better? >>> >>> common vs drvlib may not be different for who don't know about these >>> libraries, what about using "internal" or "private" kind of keyword? >> >> I am ok with librte_pvtlib_dpaa2_pmd or librte_pvtlib_dpaa2. Sounds fine? >> ('internal' is too long and its abbreviation 'int' doesn't make it easier >> to read. :D ) > > There is already "lib" in "librte". What about librte_internal_dpaa2_ prefix? > Ok. We were just trying to avoid that long name. :) > Internal is really the best word as you are requesting DPDK to host > libraries used only for your drivers. > I thought you agreed to host them outside of the DPDK repository. > What is your reason to keep pushing in DPDK? > I don't think the last discussion closed like this. You suggested [1] this as an option during handing of issue with rte.lib.mk causing the parallel build dependency of shared lib to fail for drivers/common. Ferruh has already fixed that[2]. The drivers/common is an integral part of PMD - very similar to a *base* directory of any existing DPDK PMDs. The only difference is that *NXP's base* is common across multiple drivers (bus, pool, net, crypto, eventdev etc) - all of them interface with SoC using this 'driver interface'. We named it as "driver common lib" - we could not find a better way to name it. Probably, a hw driver interface or dpaa2_base is a better explanation. Imagine a PMD which resides within DPDK (dpaa2 pmd) which only has high level interfaces with DPDK API and cannot talk to a real hardware (SoC) because it lacks the basic driver interface. That would really not make that code a 'PMD'. Probably it would be better if we close what is the scope of a PMD before this discussion is to go ahead. And, why would there be a need to store this 'lib' externally. Following is what Neil replied to your suggestion [3]. And we fully agree with it. "Please do not go with suggestion two, the more libraries get hosted outside of the project, the less likely any sort of test/build/ongoing maintenance from the community can be expected. If you're going to go with solution (2), then you may as well host the entire PMD outside of the DPDK project, and that more undesirable." [1] http://dpdk.org/ml/archives/dev/2017-January/056243.html [2] http://dpdk.org/ml/archives/dev/2017-January/056321.html [3] http://dpdk.org/ml/archives/dev/2017-January/056292.html