DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, Timothy Redaelli <tredaelli@redhat.com>,
	ferruh.yigit@intel.com, adrien.mazarguil@6wind.com
Subject: Re: [dpdk-dev] Marking symbols as experimental in the headers only
Date: Tue, 4 Dec 2018 10:14:57 -0500	[thread overview]
Message-ID: <20181204151457.GA31778@hmswarspite.think-freely.org> (raw)
In-Reply-To: <CAJFAV8x0spntK1HUWGNrsgVxqS0L-1_SauSfsUv8aFVM8q9=8g@mail.gmail.com>

On Tue, Dec 04, 2018 at 09:21:43AM +0100, David Marchand wrote:
> On Mon, Dec 3, 2018 at 5:48 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> 
> > On Mon, Dec 03, 2018 at 02:01:02PM +0100, David Marchand wrote:
> > > Hello Neil,
> > >
> > > Looking at
> > >
> > http://doc.dpdk.org/guides/contributing/versioning.html#experimental-apis,
> > > is there a real need to mark both the definition and the declaration of a
> > > symbol with the __rte_experimental marker ?
> > >
> > When I initially wrote the feature I marked both the function prototype
> > and its
> > definition with the macro to be consistent, as I like to make both
> > declaration
> > and definition look visually simmilar, just to ease readability, but I'm
> > not
> > bound to doing it that way per-se
> >
> > As to weather or not you can only mark the declaration as experimental,
> > I'm not
> > 100% sure.  I think thats an artifact of the compiler.  That is to say, the
> > macro expands to a compiler attribute that is applied at compile time, and
> > checked at link time, and I'm not sure what clang or gcc will do if there
> > is a
> > discrepancy between the attributes listed in the declaration and the
> > definition.
> >
> > I would say, give it a try, and if you can demonstrate that adding the
> > attribute
> > only to the declaration results in a link-time warning when external code
> > attempts to call an experimental function, I would have no problem
> > handling it
> > that way.
> >
> 
> Did not experiment yet, putting this in my todolist.
> Just, I can see that lib/librte_pipeline/ at least only marks the
> declarations.
> 
I just tried it. If I turn off ALLOW_EXPERIMENTAL_APIS, the ip_pipeline example
breaks with warnings about deprecated functions:

/home/nhorman/git/dpdk/examples/ip_pipeline/action.c:60:4: error: ‘rte_table_hash_crc_key8’ is deprecated: Symbol is not yet part of stable ABI [-Werror=deprecated-declarations]
    params->lb.f_hash = rte_table_hash_crc_key8;
    ^~~~~~
In file included from /home/nhorman/git/dpdk/examples/ip_pipeline/action.c:10:
/home/nhorman/git/dpdk/x86_64-native-linuxapp-gcc/include/rte_table_hash_func.h:56:1: note: declared here
 rte_table_hash_crc_key8(void *key, void *mask, __rte_unused uint32_t key_size,
 ^~~~~~~~~~~~~~~~~~~~~~~
/home/nhorman/git/dpdk/examples/ip_pipeline/action.c:64:4: error: ‘rte_table_hash_crc_key16’ is deprecated: Symbol is not yet part of stable ABI [-Werror=deprecated-declarations]
    params->lb.f_hash = rte_table_hash_crc_key16;
    ^~~~~~
...

That is sufficient for me to conclude that __rte_experimental only needs to be
set on the declaration, not the definiton as well.

If you would like to make this adjustment, I'm fine with it, though be aware,
you will likely need to make some adjustments to the check-experimental-syms
script to account for this

Neil

> 
> -- 
> David Marchand

  reply	other threads:[~2018-12-04 15:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-03 13:01 David Marchand
2018-12-03 13:26 ` Ferruh Yigit
2018-12-03 16:47 ` Neil Horman
2018-12-04  8:21   ` David Marchand
2018-12-04 15:14     ` Neil Horman [this message]
2018-12-04 20:48       ` David Marchand
2018-12-04 21:34         ` Richardson, Bruce
2018-12-05 12:21         ` Neil Horman
2018-12-05 13:22           ` David Marchand
2018-12-18 10:41             ` David Marchand
2018-12-18 12:25               ` Neil Horman
2018-12-18 12:27                 ` David Marchand
2018-12-19  9:12                   ` David Marchand
2018-12-19 12:39                     ` Neil Horman
2018-12-19 13:46                       ` David Marchand

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=20181204151457.GA31778@hmswarspite.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=tredaelli@redhat.com \
    /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).