DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
To: Neil Horman <nhorman@tuxdriver.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-dev] [EXT] Re: Re: [PATCH] devtools: skip the symbol check when map file under drivers
Date: Wed, 22 May 2019 16:22:53 +0000	[thread overview]
Message-ID: <BYAPR18MB2424CBD5F49C89C8EC996780C8000@BYAPR18MB2424.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20190522153843.GF18629@hmswarspite.think-freely.org>

> -----Original Message-----
> From: Neil Horman <nhorman@tuxdriver.com>
> Sent: Wednesday, May 22, 2019 9:09 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: 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 <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.
> >
> 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
> >
> >

  reply	other threads:[~2019-05-22 16:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 13:41 [dpdk-dev] " Jerin Jacob Kollanukkaran
2019-05-22 14:11 ` Neil Horman
2019-05-22 14:25   ` [dpdk-dev] [EXT] Re: " Jerin Jacob Kollanukkaran
2019-05-22 15:38     ` Neil Horman
2019-05-22 16:22       ` Jerin Jacob Kollanukkaran [this message]
2019-05-22 18:58         ` 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=BYAPR18MB2424CBD5F49C89C8EC996780C8000@BYAPR18MB2424.namprd18.prod.outlook.com \
    --to=jerinj@marvell.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.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).