[dpdk-dev] NXP DPAA2: Symbol renaming issue: Request for Suggestions
thomas.monjalon at 6wind.com
Tue Jan 24 17:51:36 CET 2017
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
> - 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
> - 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_*
> - 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
More information about the dev