From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
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 <dev@dpdk.org>; Tue, 24 Jan 2017 17:51:38 +0100 (CET)
Received: by mail-wm0-f47.google.com with SMTP id c85so190953555wmi.1
 for <dev@dpdk.org>; Tue, 24 Jan 2017 08:51:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=6wind-com.20150623.gappssmtp.com; s=20150623;
 h=from:to:cc:subject:date:message-id:user-agent:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=R5+8U8EZNCSpqlkPA/gTAGaEH9T7pFFlCSLeRwY8Jv8=;
 b=VBzfloI53SbIUn4Vt0d9FuB+c/b0JcoeqwqqeKyynOyBUqOpmgXVtypCRH+Fuf7lw6
 fLIp+ESlhc3eCAn8EYcYVqwmD+ReHAIUNlfKXDlIlkswU87P+jy5KQe5rZxHYlvD0Q5D
 Ev2hHQWLI6h6FpxM7lQ+UFHDGOR7JCYoeOcO6BkoDteTxG9iESqaAHfAbZ4wHglfo31F
 o1woS+nGRof5tq0Gu8f1SxXQIn99T0P5J3SojbbXM26gCRcad2xovMSHMoZjHTW+J0jw
 9iZ9Qfib3i9mjsusHr0bpXP3Wyk3P5YMrKsoNrhmMULkxuu3x6UIX+7yKJueUqp2lT1V
 YwXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent
 :in-reply-to:references:mime-version:content-transfer-encoding;
 bh=R5+8U8EZNCSpqlkPA/gTAGaEH9T7pFFlCSLeRwY8Jv8=;
 b=GdJjWqkTDhwnJn7fkEQIHfGdYgxXKQgEYPsZdnj1HagoiAGaQlFz6qWdKyDPbmsrGR
 6LDpurtzQldJt1vZW2pnC2Or7S2XYFx5+qE02SPgayJ3YxyOBpyl49Er4maM2tGEuwt8
 B07et/qIrW3wLRQOMyKP4aID3H8PfJgHBsywMCQKLGTkuYKbU7CZthfcY+lH3U8VOai8
 AEbJxEWCvj/Tbf/6NIyQpGc5VTbJC9RxynM6S+xkxt2X04RlEmKaK5VVMM+VirkW1wrS
 ySQ/b2U+UE/8Om/THjFXuJ3bobX72L/nwJi0W9/8wszQQZEzMeQ5Z+vXxpVy4sgd4x7y
 /WMg==
X-Gm-Message-State: AIkVDXK3V3JsVmsz3YhewIqHEKCCt+/iBl1p9K2L6qHxnfnSPCKdP+opPmbkngPGuQejQs1D
X-Received: by 10.223.166.106 with SMTP id k97mr30339335wrc.170.1485276697871; 
 Tue, 24 Jan 2017 08:51:37 -0800 (PST)
Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184])
 by smtp.gmail.com with ESMTPSA id b51sm20833631wrd.39.2017.01.24.08.51.37
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 24 Jan 2017 08:51:37 -0800 (PST)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev@dpdk.org,
 Hemant Agrawal <hemant.agrawal@nxp.com>
Date: Tue, 24 Jan 2017 17:51:36 +0100
Message-ID: <1605542.4lcPnkyOWx@xps13>
User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; )
In-Reply-To: <DB5PR0401MB2054D64345734B33221E332590750@DB5PR0401MB2054.eurprd04.prod.outlook.com>
References: <DB5PR0401MB2054D64345734B33221E332590750@DB5PR0401MB2054.eurprd04.prod.outlook.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] NXP DPAA2: Symbol renaming issue: Request for
	Suggestions
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2017 16:51:38 -0000

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!)
>    
>    <This is where I need you help - is there some suggestion or comments which
>     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.