From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: dev@dpdk.org
Subject: Re: [dpdk-dev] DPDK namespace
Date: Fri, 08 Apr 2016 00:01:14 +0200 [thread overview]
Message-ID: <3669443.CoLShL9pDx@xps13> (raw)
In-Reply-To: <5911950.ZPQvAWoePl@xps13>
2016-04-07 11:18, Thomas Monjalon:
> 2016-04-05 15:56, Thomas Monjalon:
> > The goal of this email is to get some feedback on how important it is
> > to fix the DPDK namespace.
>
> Everybody agree every symbols must be prefixed. Checking and fixing the
> namespace consistency will be in the roadmap.
>
> It seems most of you agree renaming would be a nice improvement but not
> so important.
The main benefits are:
- consistency with the name of the project
- avoid a namespace clash with another library using "rte" prefix
(the dpdk word is kind of reserved now)
> The main drawback is the induced backporting pain, even if we have
> some scripts to convert the patches to the old namespace.
> Note: the backports can be in DPDK itself or in the applications.
>
> > If there is enough agreement that we should do something, I suggest to
> > introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_"
> > during some time.
> > We could start using the new prefix for the new APIs (example: crypto)
> > or when there is a significant API break (example: mempool).
>
> The slow change has been clearly rejected in favor of a complete change
> in one patch.
> The timing was also discussed as it could impact the pending patches.
> So it would be done at the end or the beginning of a release.
> Marc suggests to do it for 16.04 as the numbering scheme has changed.
>
> There is no strong conclusion at this point because we need to decide
> wether the renaming deserves to be done or never.
> I suggest to take the inputs from the technical board.
The technical board has agreed that the renaming cannot happen in 16.04.
The pro/cons balance need to be discussed more.
The plan is to keep the discussion open during the next 2 weeks and
take a decision based on the discussion outcome.
prev parent reply other threads:[~2016-04-07 22:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 13:56 Thomas Monjalon
2016-04-05 14:13 ` Trahe, Fiona
2016-04-05 14:31 ` Trahe, Fiona
2016-04-05 14:31 ` Arnon Warshavsky
2016-04-06 5:26 ` Yuanhan Liu
2016-04-06 12:07 ` Panu Matilainen
2016-04-06 12:34 ` Ananyev, Konstantin
2016-04-06 14:36 ` Wiles, Keith
2016-04-06 20:21 ` Dave Neary
2016-04-07 8:22 ` Marc
2016-04-11 16:10 ` Don Provan
2016-04-11 16:28 ` Thomas Monjalon
2016-04-06 12:41 ` Jay Rolette
2016-04-06 12:51 ` Mcnamara, John
2016-04-07 9:18 ` Thomas Monjalon
2016-04-07 9:33 ` Panu Matilainen
2016-04-07 10:16 ` Marc Sune
2016-04-07 11:51 ` [dpdk-dev] On DPDK ABI policy Panu Matilainen
2016-04-07 21:52 ` Matthew Hall
2016-04-08 8:29 ` Marc Sune
2016-04-08 8:47 ` Marc Sune
2016-04-07 21:48 ` [dpdk-dev] DPDK namespace Matthew Hall
2016-04-07 22:01 ` Thomas Monjalon [this message]
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=3669443.CoLShL9pDx@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
/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).