Re: [dpdk-dev] [EXT] Re: Re: [PATCH] devtools: skip the symbol check when map file under drivers

[Jerin Jacob Kollanukkaran <jerinj@marvell.com>]

> -----Original Message-----
> From: Neil Horman <nhorman@tuxdriver.com>
> Sent: Wednesday, May 22, 2019 7:41 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;
> thomas@monjalon.net; stable@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 <nhorman@tuxdriver.com>
> > > Sent: Wednesday, May 22, 2019 6:43 PM
> > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > Cc: Bruce Richardson <bruce.richardson@intel.com>; dev@dpdk.org;
> > > thomas@monjalon.net; stable@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.richardson@intel.com>
> > > > > Sent: Wednesday, May 22, 2019 4:21 PM
> > > > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > > > Cc: Neil Horman <nhorman@tuxdriver.com>; dev@dpdk.org;
> > > > > thomas@monjalon.net; stable@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. 

Anyway I will add experimental section to make tool happy.