[dpdk-dev] [PATCH v2] ethdev: introduce enable_driver_sdk to install driver headers
Ferruh Yigit
ferruh.yigit at intel.com
Mon Mar 29 11:43:09 CEST 2021
On 3/26/2021 8:52 PM, Tyler Retzlaff wrote:
> On Fri, Mar 26, 2021 at 12:02:55PM +0000, Ferruh Yigit wrote:
>> On 3/24/2021 4:24 PM, Tyler Retzlaff wrote:
>>> On Wed, Mar 24, 2021 at 12:30:36PM +0100, Thomas Monjalon wrote:
>>>> 24/03/2021 12:27, Ferruh Yigit:
>>>>>
>>>>> But not sure how to manage the same problem for whole project, if install all
>>>>> headers in one patch, or add them gradually via separate patches by time ...
>>>>
>>>> We did a cleanup in ethdev but not in other driver classes.
>>>> When the cleanup will be done gradually, the headers
>>>> must move in this new category driver_sdk_headers.
>>>
>>> yes, some headers are not installed now. so they need only to have
>>> their api marked __rte_internal and installed (since there should be no
>>> external consumer as a function of not being installed)
>>>
>>> the more difficult case is where headers were installed but the api were
>>> not marked __rte_internal and appear in the stable version.map. for
>>> those i guess deprecation notice has to be issued before marking as
>>> internal.
>>>
>>
>> Are you referring to any specific APIs, can you share list of them?
>
> i can't remember the whole list but Thomas originally indicated the
> following candidate list.
>
> baseband/ -> librte_bbdev/rte_bbdev_pmd.h
> bus/ -> rte_bus.h
> common/ -> no interface
> crypto/ -> librte_cryptodev/rte_cryptodev_pmd.h
> event/ -> librte_eventdev/
> mempool/ -> librte_mempool/
> net/ -> librte_ethdev/
> raw/ -> librte_rawdev/rte_rawdev_pmd.h
> regex/ -> librte_regexdev/rte_regexdev_driver.h
> vdpa/ -> librte_vhost/rte_vdpa_dev.h
>
> some of these headers are not published, some are.
>
These are public headers, so they should not have '__rte_internal' functions,
are you saying some of public headers has internal functions that are presented
as public APIs?
More information about the dev
mailing list