From: Arnon Warshavsky <arnon@qwilt.com>
To: "Trahe, Fiona" <fiona.trahe@intel.com>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK namespace
Date: Tue, 5 Apr 2016 17:31:22 +0300 [thread overview]
Message-ID: <CAKy9EB3wT0nXQ7P8nuUY2hJ=Kdyip7jCP9ypka=EVGO2CB_HKg@mail.gmail.com> (raw)
In-Reply-To: <348A99DA5F5B7549AA880327E580B43588FC621D@IRSMSX101.ger.corp.intel.com>
On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona <fiona.trahe@intel.com> wrote:
>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Tuesday, April 05, 2016 2:57 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] DPDK namespace
> >
> > DPDK is going to be more popular in Linux distributions.
> > It means people will have some DPDK files in their /usr/include and some
> DPDK
> > libraries on their system.
> >
> > Let's imagine someone trying to compile an application which needs
> > rte_ethdev.h. He has to figure out that this "rte header" is provided by
> the DPDK.
> > Hopefully it will be explained on StackOverflow that RTE stands for DPDK.
> > Then someone else will try to run a binary without having installed the
> DPDK
> > libraries. The linker will require libethdev.so (no prefix here).
> > StackOverflow will probably have another good answer (among wrong ones):
> > "Hey Sherlock Holmes, have you tried to install the DPDK library?"
> > Followed by an insight: "You know, the DPDK naming is weird..."
> > And we could continue the story with developers having some naming clash
> > because of some identifiers not prefixed at all.
> >
> > The goal of this email is to get some feedback on how important it is to
> fix the
> > DPDK namespace.
> >
> > 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).
> >
> > Opinions welcome!
> I don't have an opinion on how important it is to fix the namespace,
> though it does seem like a good idea.
> However if it's to be done, in my opinion it should be completed quickly
> or will just cause more confusion.
> So if rte_cryptoxxx becomes dpdk_cryptoxxx all other libraries should
> follow in next release or two, with
> the resulting ABI compatibility handling. Maybe with dual naming handled
> for several releases, but a
> clear end date when all are converted.
> Else there will be many years with a mix of rte_ and dpdk_
>
>
Googling rte functions or error codes usually takes you to dpdk dev email
archive so I don't think it is that much difficult to figure out where rte
comes from.
Other than that , except for my own refactoring pains when replacing a dpdk
version, I do not see a major reason why not.
If Going for dpdk_ prefix, I agree with the quick death approach.
/Arnon
next prev parent reply other threads:[~2016-04-05 14:31 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 [this message]
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
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='CAKy9EB3wT0nXQ7P8nuUY2hJ=Kdyip7jCP9ypka=EVGO2CB_HKg@mail.gmail.com' \
--to=arnon@qwilt.com \
--cc=dev@dpdk.org \
--cc=fiona.trahe@intel.com \
--cc=thomas.monjalon@6wind.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).