> -----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. I don't think, giving experimental status to intra driver API helps anyone, neither driver nor application. If you think strongly that experimental needs to be added for intra driver APIs then I can add that. > and so you have a responsibility to keep it stable for those users. > > Currently the way we have around that is the use of the __rte_experimental > tag. > Adding that tag to an exported function marks it as being unstable, and while > you can use it, it will generate a build time warning about its use, unless > you > define ALLOW_EXPERIMENTAL_API. You could use that, understanding that > in-tree drivers could use it safely, as you should always be keeping the API > in > sync with its users, but thats not quite what you want I don't think. > > Another solution (allbeit a slightly risky one), would be to bifurcate your > header files into a public and private version, with the private version > prototyping your driver-only functions properly, and the public version > aliasing them such that they generate a build time error indicating those > functions aren't available for public use (you can use the gcc static_assert > macro I believe). Users could circumvent it by pulling the private header out > of the build, or just prototyping the functions themselves, but at that point > a > user is asking for trouble anyway > > Neil
