DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gajdzica, MaciejX T" <maciejx.t.gajdzica@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Issue with rte_compat versioning macros
Date: Mon, 22 Jun 2015 15:32:01 +0000	[thread overview]
Message-ID: <9CC680510C0AC140A846FED2EF7F96281384660E@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <20150619153208.GC4619@hmsreliant.think-freely.org>

Hi Neil

> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Friday, June 19, 2015 5:32 PM
> To: Gajdzica, MaciejX T
> Cc: Thomas Monjalon; dev@dpdk.org
> Subject: Re: [dpdk-dev] Issue with rte_compat versioning macros
> 
> On Fri, Jun 19, 2015 at 03:04:17PM +0000, Gajdzica, MaciejX T wrote:
> > > -----Original Message-----
> > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > Sent: Friday, June 19, 2015 4:48 PM
> > > To: Gajdzica, MaciejX T
> > > Cc: dev@dpdk.org; nhorman@tuxdriver.com
> > > Subject: Re: [dpdk-dev] Issue with rte_compat versioning macros
> > >
> > > 2015-06-19 14:38, Gajdzica, MaciejX T:
> > > > There is an issue with macros in rte_compat.h. For shared library
> > > > case, macro BIND_DEFAULT_SYMBOL takes three arguments and for
> > > > other case it takes only two arguments. Also letters for macro
> > > > variable names are
> > > not consistent in these two cases.
> > >
> > > Yes, and your patch fix it:
> > > 	http://dpdk.org/dev/patchwork/patch/5475/
> > > But it is part of a series which is not accepted yet.
> > >
> > > It would be faster merged if you send it as a standalone patch.
> > > Thanks
> >
> > But simple solution with adding third argument to static library case doesn't
> work. Comment in rte_compat.h file describes steps needed to add new version
> of the function and it says:
> >
> > * 2) rename the existing function int foo(char *string) to
> > * 	int __vsym foo_v20(char *string)
> > *
> > * 3) Add this macro immediately below the function
> > * 	VERSION_SYMBOL(foo, _v20, 2.0);
> > *
> > * 4) Implement a new version of foo.
> > * 	char foo(int value, int otherval) { ...}
> > *
> > * 5) Mark the newest version as the default version
> > * 	BIND_DEFAULT_SYMBOL(foo, 2.1);
> >
> > So probably BIND_DEFAULT_SYMBOL macro for shared library case needs to
> be modified to have two arguments.
> > I'm not familiar with that symver syntax so I need some help. It would be
> better when original author say how it should look like.
> >
> > Best Regards
> > Maciek
> >
> >
> 
> No adding the third parameter will work just fine.  The documentation needs to
> be updated as well to reflect the 3rd argument:
> * 5) Mark the newest version as the default version
> *      BIND_DEFAULT_SYMBOL(foo, foo, 2.1);
> 
> 
> Neil
> 

For me versioning still don't work, even though I try to do it as you say. I had function:

int
rte_cfgfile_section_entries(struct rte_cfgfile *cfg,
	const char *sectionname,
	struct rte_cfgfile_entry *entries,
	int max_entries)
{
[...]
}

And I wanted to add new version of it. So I marked it as _v20, added version macro,
added new implementation and default symbol macro:

int __vsym
rte_cfgfile_section_entries_v20(struct rte_cfgfile *cfg,
	const char *sectionname,
	struct rte_cfgfile_entry *entries,
	int max_entries)
{
[...]
}
VERSION_SYMBOL(rte_cfgfile_section_entries, _v20, 2.0);

int __vsym
rte_cfgfile_section_entries(struct rte_cfgfile *cfg,
		const char *sectionname, struct rte_cfgfile_entry2 **entries,
		int max_entries)
{
[...]
}
BIND_DEFAULT_SYMBOL(rte_cfgfile_section_entries, rte_cfgfile_section_entries, 2.1);

I edited map file so it looks like this:

DPDK_2.0 {
	global:

[...]
	rte_cfgfile_section_entries;
[...]

	local: *;
};

DPDK_2.1 {
	global:

	rte_cfgfile_section_entries;

	local: *;
};

Then I try to build dpdk and qos_sched example which uses this function. When I build dpdk
as static library, everything works fine. When I build dpdk as shared library, compilation of example
returns error, that it doesn't see rte_cfgfile_section_entries function.

Maybe I do something wrong, but it's obvious that better documentation is needed. In current
dpdk master code, versioning is not used. There are only 2 patchsets that tries to use it. This one and:
http://dpdk.org/ml/archives/dev/2015-May/018169.html
That second one probably uses it wrong, because second argument of BIND_DEFAULT_SYMBOL is _v21.
And you said, it should be the same as function name. I don't need versioning for now as we decided
That rte_cfgfile modifications should be done in next release. But knowing that versioning macros
are well documented and work properly could encourage more people to use it.

Best Regards
Maciek

  reply	other threads:[~2015-06-22 15:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-19 14:38 Gajdzica, MaciejX T
2015-06-19 14:48 ` Thomas Monjalon
2015-06-19 15:04   ` Gajdzica, MaciejX T
2015-06-19 15:32     ` Neil Horman
2015-06-22 15:32       ` Gajdzica, MaciejX T [this message]
2015-06-22 16:51         ` Neil Horman
2015-06-23  7:45           ` Gajdzica, MaciejX T
2015-06-23 11:28             ` Gajdzica, MaciejX T

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=9CC680510C0AC140A846FED2EF7F96281384660E@IRSMSX102.ger.corp.intel.com \
    --to=maciejx.t.gajdzica@intel.com \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.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).