29/03/2021 17:23, Ferruh Yigit: > On 3/29/2021 1:10 PM, Thomas Monjalon wrote: > > 29/03/2021 11:43, Ferruh Yigit: > >> 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? > > > > These are the headers for use by the drivers. > > We should classify them as SDK headers, not API. > > > > Yes, you are right, they shouldn't be public header. > > So, agree to Tyler's comment, that some of those functions needs to be > removed > from the stable API list first, which will take time. > > I can proceed with the ethdev one, any objection?
+1 > And for the rest of the list, how can we fix them? I guess best option is to > distribute the work to each library, but we need an owner of the task to > follow > and communicate it. +1 +Cc techboard
