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, 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
