From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: NXP DPAA2: Symbol renaming issue: Request for Suggestions Date: Tue, 24 Jan 2017 17:51:36 +0100 Message-ID: <1605542.4lcPnkyOWx@xps13> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Ferruh Yigit , dev@dpdk.org, Hemant Agrawal To: Shreyansh Jain Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 9654E108F for ; Tue, 24 Jan 2017 17:51:38 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id c85so190953555wmi.1 for ; Tue, 24 Jan 2017 08:51:38 -0800 (PST) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2017-01-24 14:39, Shreyansh Jain: > You might have noticed that we have exposed a lot of symbols from > drivers/common and drivers/bus for drivers/net and drivers/crypto. All these > symbols are not rte_* as what has been suggested for exported symbols. > > Review comments have been received for renaming these to make them rte_* or > _rte_* prefixed. > > Just as a side note, these symbols are being exposed _internally_ within > drivers/* area. > > There are (3) possible solutions we have: > > 1/ Rename all the symbols: > - This is a difficult option for us. Renaming means breaking our linkage > with existing code (Linux Kernel upstream candidate as well as internal > repository). > - Changing it means maintaining this change set internally/independently > which is not a feasible long term solution. I don't understand the problem. You can have a DPDK layer which rename functions and structs. > 2/ Merge all the libraries together: > - In the initial RFC days, there were review comments which suggested that > we should break the PMD into common libraries and place it in drivers/* > parallel folders. > - This is precisely the reason we are facing the situation. > - Another possibility is to start duplicating the code for common. But, this > too has a technical limitation for us as some data structures are shared > across net and crypto and it is not possible to have multiple instances of > those. > - One more offshoot option could have been to keep the library external > of the DPDK framework (external location and linked on demand basis, > manually). We don't prefer this as this will make it difficult for any user > to use DPAA2 easily. Yes, it was my first comment. If this layer is common with other projects, why not maintaining it as a standalone library? > 3/ Finding a way to keep symbols internal to drivers/* independent of rte_* > prefix: > - For example, allowing symbols to be exposed limited to drivers/* area > and not allowing them to be available across lib/* (not sure how, though!) > > can help us arrive to a solution?> There is currently no difference between API symbols and inter-libs symbols. > My argument for this: > - With new bus infra in place, there would be more drivers being contributed. > It also means that there would be PMDs having their own code and symbol > models. It would be difficult to ask all of them to mandatorily adhere > to a naming scheme. > This argument bodes well for lib/* because that is core (libraries) which > should be controlled for uniformity and performance. I think it is acceptable to have some DPAA2-specific symbols with their own namespace.