> -----Original Message----- > From: Neil Horman <nhor...@tuxdriver.com> > Sent: Wednesday, May 22, 2019 9:09 PM > To: Jerin Jacob Kollanukkaran <jer...@marvell.com> > Cc: Bruce Richardson <bruce.richard...@intel.com>; dev@dpdk.org; > tho...@monjalon.net; sta...@dpdk.org > Subject: Re: [EXT] Re: [dpdk-dev] Re: [PATCH] devtools: skip the symbol > check when map file under drivers > > On Wed, May 22, 2019 at 02:25:14PM +0000, Jerin Jacob Kollanukkaran wrote: > > > -----Original Message----- > > > From: Neil Horman <nhor...@tuxdriver.com> > > > Sent: Wednesday, May 22, 2019 7:41 PM > > > To: Jerin Jacob Kollanukkaran <jer...@marvell.com> > > > Cc: Bruce Richardson <bruce.richard...@intel.com>; dev@dpdk.org; > > > tho...@monjalon.net; sta...@dpdk.org > > > Subject: [EXT] Re: [dpdk-dev] Re: [PATCH] devtools: skip the symbol > > > check when map file under drivers > > > > > > External Email > > > > > > -------------------------------------------------------------------- > > > -- On Wed, May 22, 2019 at 01:41:03PM +0000, Jerin Jacob > > > Kollanukkaran wrote: > > > > > -----Original Message----- > > > > > From: Neil Horman <nhor...@tuxdriver.com> > > > > > Sent: Wednesday, May 22, 2019 6:43 PM > > > > > To: Jerin Jacob Kollanukkaran <jer...@marvell.com> > > > > > Cc: Bruce Richardson <bruce.richard...@intel.com>; dev@dpdk.org; > > > > > tho...@monjalon.net; sta...@dpdk.org > > > > > Subject: [EXT] Re: [dpdk-dev] Re: [PATCH] devtools: skip the > > > > > symbol check when map file under drivers > > > > > > > > > > External Email > > > > > > > > > > ---------------------------------------------------------------- > > > > > ---- > > > > > -- On Wed, May 22, 2019 at 11:54:13AM +0000, Jerin Jacob > > > > > Kollanukkaran > > > > > wrote: > > > > > > > -----Original Message----- > > > > > > > From: Bruce Richardson <bruce.richard...@intel.com> > > > > > > > Sent: Wednesday, May 22, 2019 4:21 PM > > > > > > > To: Jerin Jacob Kollanukkaran <jer...@marvell.com> > > > > > > > Cc: Neil Horman <nhor...@tuxdriver.com>; dev@dpdk.org; > > > > > > > tho...@monjalon.net; sta...@dpdk.org > > > > > > > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] devtools: skip the > > > > > > > symbol check when map file under drivers > > > > > > > > > > > > > > > > Sorry, but I'm not ok with this, because many of our > > > > > > > > > DPDK PMDs have functions that get exported which are > > > > > > > > > meant to be called by applications directly. The > > > > > > > > > > > > > > > > OK. Just to update my knowledge, Should those API needs to > > > > > > > > go through ABI/API depreciation process? > > > > > > > > > > > > > > > > Actually, I am concerned about the APIs, which is called > > > > > > > > between drviers not the application. For example, > > > > > > > > drivers/common/dpaax/rte_common_dpaax_version.map > > > > > > > > > > > > > > > > it is not interface to application rather it is for intra > > > > > > > > driver case. > > > > > > > > I think, I can change my logic to Skip the symbols which > > > > > > > > NOT starting with > > > > > > > rte_. > > > > > > > > Agree? > > > > > > > > > > > > > > > > Context: > > > > > > > > I am adding a new driver/common/octeontx2 directory and it > > > > > > > > has some API which Needs to shared between drivers not to > > > > > > > > the application. For me, it does not make sense to go > > > > > > > > through any ABI > > > > > process in such case. > > > > > > > > > > > > > > > > > > > > > > > Maybe not, but other drivers will have APIs designed for > > > > > > > apps to call directly - some NIC drivers have them, and I > > > > > > > suspect that rawdev drivers will need them a lot. Therefore, > > > > > > > it's best to have the drivers directory scanned by our tooling. > > > > > > > > > > > > Agreed. But all of those API which called directly called > > > > > > from application is starts with rte_ symbol. How about > > > > > > skipping the symbols which is NOT start with rte_* > > > > > > example: > > > > > > drivers/common/octeontx/rte_common_octeontx_version.map > > > > > > drivers/common/dpaax/rte_common_dpaax_version.map > > > > > > > > > > > > > > > > No, that won't work. If you export a function, it doesn't > > > > > matter if its named > > > > > rte_* or not. Its accessible from any library/application that > > > > > cares to call it, > > > > > > > > IMO, The name prefix matters. The rte_* should denote it a DPDK > > > > API and application suppose to use it. > > > > > > > It doesn't, its just a convention. We have no documentation that > > > indicates what the meaning of an rte_* prefix is specficially, above > > > and beyond the fact thats how we name functions in the DPDK. If you > > > want to submit a patch to formalize the meaning of function > > > prefixes, you're welcome too (though I won't support it, perhaps > > > others will). But even if you do, it doesn't address the underlying > > > problem, which is that applications still have access to those symbols. > > > Maintaining an ABI by assertion of prefix is really a lousy way to > > > communicate what functions should be accessed by an application and > > > which shouldn't. If a function is exported, and included in the > > > header file, people will try to use > > > > The current scheme in the driver/common is that, the header files are > > NOT made It as public ie not installed make install. > > The consumer driver includes that using relative path wrt DPDK source > directory. > > > Well, thats a step in the right direction. I'd still like to see some > enforcement > to prevent the inadvertent use of those APIs though
Yes header file is not exported. Not sure how a client can use those. Other than doing some hacking. > > > Anyway I will add experimental section to make tool happy. > > > That really not the right solution. Marking them as experimental is just > papering over the problem, and suggests to users that they will one day be > stable. That what my original concern. > What you want is to explicitly mark those symbols as internal only, so > that any inadvertent use gets flagged. What is your final thought? I can assume the following for my patch generation # No need to mark as experimental # Add @internal to denote it is a internal function like followed some places in EAL. > > Neil > > > >
