From: Neil Horman <nhorman@tuxdriver.com>
To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [dpdk-dev] Re: [PATCH] devtools: skip the symbol check when map file under drivers
Date: Wed, 22 May 2019 10:11:16 -0400 [thread overview]
Message-ID: <20190522141116.GD18629@hmswarspite.think-freely.org> (raw)
In-Reply-To: <BYAPR18MB24243FB63048208D2C92632DC8000@BYAPR18MB2424.namprd18.prod.outlook.com>
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
them. You need an enforcement mechanism to call attention to the fact that they
are unusable in normal operation
> I don't think, giving experimental status to intra driver API helps anyone, neither driver nor
> application.
>
Nor do I, I was just using it as an example of how you might create an
enforcement mechanism. I think a better solution is bifurcating your headers
to a public and private version, in which the former defines apis you wish to be
generally inaccessable to a static_assert that causes a build time error for
uses that are not 'DPDK internal'
> If you think strongly that experimental needs to be added for intra driver APIs then I can add that.
>
No, I don't, I was just using that as an example of what you might do. I think
the header solution is far more appropriate for this case.
Neil
next prev parent reply other threads:[~2019-05-22 14:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-22 13:41 Jerin Jacob Kollanukkaran
2019-05-22 14:11 ` Neil Horman [this message]
2019-05-22 14:25 ` [dpdk-stable] [EXT] " Jerin Jacob Kollanukkaran
2019-05-22 15:38 ` Neil Horman
2019-05-22 16:22 ` Jerin Jacob Kollanukkaran
2019-05-22 18:58 ` Neil Horman
-- strict thread matches above, loose matches on Subject: below --
2019-05-23 14:21 [dpdk-stable] " Jerin Jacob Kollanukkaran
2019-05-23 17:57 ` Neil Horman
2019-05-23 18:59 ` Thomas Monjalon
2019-05-23 20:17 ` Neil Horman
2019-05-22 11:54 Jerin Jacob Kollanukkaran
2019-05-22 13:13 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190522141116.GD18629@hmswarspite.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=stable@dpdk.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).