DPDK patches and discussions
 help / color / mirror / Atom feed
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>
Subject: Re: [dpdk-dev] NXP DPAA2: Symbol renaming issue: Request for Suggestions
Date: Tue, 24 Jan 2017 17:51:36 +0100	[thread overview]
Message-ID: <1605542.4lcPnkyOWx@xps13> (raw)
In-Reply-To: <DB5PR0401MB2054D64345734B33221E332590750@DB5PR0401MB2054.eurprd04.prod.outlook.com>

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.

  parent reply	other threads:[~2017-01-24 16:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-24 14:39 Shreyansh Jain
2017-01-24 16:24 ` Ferruh Yigit
2017-01-25 11:35   ` Shreyansh Jain
2017-01-24 16:51 ` Thomas Monjalon [this message]
2017-01-25 12:37 ` Neil Horman
2017-01-25 13:00   ` Shreyansh Jain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1605542.4lcPnkyOWx@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=shreyansh.jain@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).