From: Neil Horman <nhorman@tuxdriver.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Ferruh Yigit <ferruh.yigit@intel.com>,
john.mcnamara@intel.com, bruce.richardson@intel.com
Subject: Re: [dpdk-dev] [PATCHv4 3/5] Makefiles: Add experimental tag check and warnings to trigger on use
Date: Sun, 21 Jan 2018 20:34:17 -0500 [thread overview]
Message-ID: <20180122013417.GB5415@neilslaptop.think-freely.org> (raw)
In-Reply-To: <2231669.8C7kkI4IjB@xps>
On Sun, Jan 21, 2018 at 07:54:44PM +0100, Thomas Monjalon wrote:
> 12/01/2018 13:44, Neil Horman:
> > On Fri, Jan 12, 2018 at 11:49:57AM +0000, Ferruh Yigit wrote:
> > > On 1/11/2018 8:50 PM, Neil Horman wrote:
> > > > On Thu, Jan 11, 2018 at 08:06:43PM +0000, Ferruh Yigit wrote:
> > > >> On 12/13/2017 3:17 PM, Neil Horman wrote:
> > > >>> --- a/app/test-eventdev/Makefile
> > > >>> +++ b/app/test-eventdev/Makefile
> > > >>> @@ -32,6 +32,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
> > > >>>
> > > >>> APP = dpdk-test-eventdev
> > > >>>
> > > >>> +CFLAGS += -DALLOW_EXPERIMENTAL_APIS
> > > >>
> > > >> Do we need this internally in DPDK? For application developers this is great,
> > > >> they will get warning unless explicitly stated that they are OK with it.
> > > >>
> > > > I'm not sure what you're asking here. As I mentioned in the initial post, I
> > > > think we should give blanket permission to any in-tree dpdk library to allow the
> > > > use of experimental API's, but that doesn't really imply that all developers
> > > > would wan't it disabled all the time. That is to say, I could envision a
> > > > library author who, early in development would want to get a warning issued if
> > > > they used an unstable API, and, only once they were happy with their design and
> > > > choice of API usage, turn the warning off.
> > >
> > > I got your point, but I think whoever using an experimental API in another
> > > component in DPDK is almost always the author of the that experimental API, so
> > > not sure this check is ever really needed within dpdk.
> > >
> > I would have thought so too, but it doesn't really bear up. The example I used
> > to convince myself of a more granular approach was commit
> > 9c38b704d280ac128003238d7d80bf07fa556a7d where the rte_service API was
> > introduced as experimental by Nikhil Rao, and then later used in the eal library
> > as part of commit a894d4815f79b0d76527d9c42b23327de1501711 by Harry van Haaren.
> > Its no big deal because, as we agree, internal usage should be considered safe,
> > but it seemed clear that differing authors were using each others code
> > (potentially oblivious to the experimental nature of those APIs)
> >
> > > But OK, I guess it won't hurt to have more granular approach.
> > >
> > > >
> > > >> Do we have any option than allowing them in DPDK library? And when experimental
> > > >> API modified the users in the DPDK library internally guaranteed to be updated.
> > > >> Why not globally allow this for all DPDK internally?
> > > >>
> > > > For the reason I gave above. We certainly could enable this in a more top-level
> > > > makefile so that for in-library systems it was opt-in rather than opt-out, but I
> > > > chose a more granular approach because I could envision newer libraries wanting
> > > > it on. I also felt, generally speaking, that where warning flags were
> > > > concerned, it generally desireous to have them on by default, and make people
> > > > explicitly choose to turn them off.
>
> I think DPDK developpers look at the EXPERIMENTAL warning in the doxygen
> above the prototype.
I'm not sure I agree with that, but regardless, my initial reasoning for writing
this tag was to call attention to experimental API's during review, rather than
their use during development, so I didn't gripe about ABI changes on expemted
code. Additionally, weather they look at the docs or not, they can
pre-emptively turn off the warning if they choose.
> And when API will be switched to stable, we probably won't remove the flag
> in the makefile to disable allowing experimental.
Well, that remains to be seen I suppose.
> So at the end, we could just allow experimental API for all internal libs.
Thats a rather bootstrapping argument. You are effecitvely saying that no one
developing will ever want to be warned of using experimental APIs in DPDK, so
lets just turn it off everyone. I would really rather let individual developers
make that call at the time they author something new.
>
next prev parent reply other threads:[~2018-01-22 1:34 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-01 18:56 [dpdk-dev] [PATCH 0/4] dpdk: enhance EXPERIMENTAL api tagging Neil Horman
2017-12-01 18:56 ` [dpdk-dev] [PATCH 1/4] buildtools: Add tool to check EXPERIMENTAL api exports Neil Horman
2017-12-01 18:56 ` [dpdk-dev] [PATCH 2/4] compat: Add __experimental macro Neil Horman
2017-12-01 18:56 ` [dpdk-dev] [PATCH 3/4] dpdk: add __experimental tag to appropriate api calls Neil Horman
2017-12-01 18:56 ` [dpdk-dev] [PATCH 4/4] Makefiles: Add experimental tag check and warnings to trigger on use Neil Horman
2017-12-08 17:14 ` [dpdk-dev] [PATCHv2 0/4] dpdk: enhance EXPERIMENTAL api tagging Neil Horman
2017-12-08 17:14 ` [dpdk-dev] [PATCHv2 1/4] buildtools: Add tool to check EXPERIMENTAL api exports Neil Horman
2017-12-08 17:14 ` [dpdk-dev] [PATCHv2 2/4] compat: Add __experimental macro Neil Horman
2017-12-08 17:14 ` [dpdk-dev] [PATCHv2 3/4] Makefiles: Add experimental tag check and warnings to trigger on use Neil Horman
2017-12-11 11:35 ` Bruce Richardson
2017-12-11 12:40 ` Neil Horman
2017-12-11 12:45 ` Bruce Richardson
2017-12-11 18:44 ` Neil Horman
2017-12-08 17:14 ` [dpdk-dev] [PATCHv2 4/4] dpdk: add __experimental tag to appropriate api calls Neil Horman
2017-12-11 19:36 ` [dpdk-dev] [PATCHv3 0/4] dpdk: enhance EXPERIMENTAL api tagging Neil Horman
2017-12-11 19:36 ` [dpdk-dev] [PATCHv3 1/4] buildtools: Add tool to check EXPERIMENTAL api exports Neil Horman
2017-12-11 19:36 ` [dpdk-dev] [PATCHv3 2/4] compat: Add __experimental macro Neil Horman
2017-12-11 19:36 ` [dpdk-dev] [PATCHv3 3/4] Makefiles: Add experimental tag check and warnings to trigger on use Neil Horman
2017-12-11 19:36 ` [dpdk-dev] [PATCHv3 4/4] dpdk: add __experimental tag to appropriate api calls Neil Horman
2017-12-12 14:07 ` [dpdk-dev] [PATCHv3 0/4] dpdk: enhance EXPERIMENTAL api tagging Bruce Richardson
2017-12-30 17:15 ` Neil Horman
2018-01-04 12:56 ` Neil Horman
2018-01-05 14:08 ` Thomas Monjalon
2018-01-05 16:00 ` Neil Horman
2018-01-09 1:32 ` [dpdk-dev] [dpdk-ci] " Neil Horman
2018-01-09 9:20 ` Thomas Monjalon
2018-01-09 12:36 ` Neil Horman
2018-01-19 15:44 ` Neil Horman
2017-12-12 14:33 ` [dpdk-dev] " Mcnamara, John
2017-12-12 20:18 ` Neil Horman
2017-12-12 15:11 ` Wiles, Keith
2017-12-12 20:14 ` Neil Horman
2017-12-13 15:17 ` [dpdk-dev] [PATCHv4 " Neil Horman
2017-12-13 15:17 ` [dpdk-dev] [PATCHv4 1/5] buildtools: Add tool to check EXPERIMENTAL api exports Neil Horman
2018-01-21 18:31 ` Thomas Monjalon
2018-01-21 22:07 ` Neil Horman
2017-12-13 15:17 ` [dpdk-dev] [PATCHv4 2/5] compat: Add __experimental macro Neil Horman
2018-01-21 18:37 ` Thomas Monjalon
2017-12-13 15:17 ` [dpdk-dev] [PATCHv4 3/5] Makefiles: Add experimental tag check and warnings to trigger on use Neil Horman
2018-01-11 20:06 ` Ferruh Yigit
2018-01-11 20:50 ` Neil Horman
2018-01-12 11:49 ` Ferruh Yigit
2018-01-12 12:44 ` Neil Horman
2018-01-21 18:54 ` Thomas Monjalon
2018-01-22 1:34 ` Neil Horman [this message]
2018-01-22 1:37 ` Thomas Monjalon
2018-01-21 18:50 ` Thomas Monjalon
2018-01-22 1:19 ` Neil Horman
2017-12-13 15:17 ` [dpdk-dev] [PATCHv4 4/5] dpdk: add __experimental tag to appropriate api calls Neil Horman
2018-01-11 20:06 ` Ferruh Yigit
2018-01-11 21:24 ` Neil Horman
2018-01-12 11:50 ` Ferruh Yigit
2018-01-12 14:25 ` Neil Horman
2018-01-12 15:53 ` Ferruh Yigit
2017-12-13 15:17 ` [dpdk-dev] [PATCHv4 5/5] doc: Add ABI __experimental tag documentation Neil Horman
2017-12-13 15:32 ` Bruce Richardson
2018-01-11 20:06 ` Ferruh Yigit
2018-01-11 21:29 ` Neil Horman
2018-01-12 11:50 ` Ferruh Yigit
2018-01-12 14:37 ` Neil Horman
2018-01-12 15:55 ` Ferruh Yigit
2018-01-13 0:28 ` Neil Horman
2018-01-13 15:56 ` Thomas Monjalon
2018-01-14 14:36 ` Neil Horman
2018-01-14 16:27 ` Thomas Monjalon
2018-01-21 20:14 ` Thomas Monjalon
2017-12-13 15:32 ` [dpdk-dev] [PATCHv4 0/4] dpdk: enhance EXPERIMENTAL api tagging Bruce Richardson
2017-12-21 14:21 ` Neil Horman
2017-12-30 19:20 ` Luca Boccassi
2017-12-31 1:57 ` Neil Horman
2018-01-22 1:48 ` [dpdk-dev] [PATCH 0/5] " Neil Horman
2018-01-22 1:48 ` [dpdk-dev] [[PATCH v5] 1/5] buildtools: Add tool to check EXPERIMENTAL api exports Neil Horman
2018-01-22 1:48 ` [dpdk-dev] [[PATCH v5] 2/5] compat: Add __rte_experimental macro Neil Horman
2018-01-22 1:48 ` [dpdk-dev] [[PATCH v5] 3/5] Makefiles: Add experimental tag check and warnings to trigger on use Neil Horman
2018-01-22 1:48 ` [dpdk-dev] [[PATCH v5] 4/5] dpdk: add __rte_experimental tag to appropriate api calls Neil Horman
2018-01-22 1:48 ` [dpdk-dev] [[PATCH v5] 5/5] doc: Add ABI __experimental tag documentation Neil Horman
2018-01-23 10:35 ` Mcnamara, John
2018-01-29 21:42 ` Thomas Monjalon
2018-01-29 21:46 ` [dpdk-dev] [PATCH 0/5] dpdk: enhance EXPERIMENTAL api tagging Thomas Monjalon
2018-01-30 15:54 ` Neil Horman
2018-01-30 16:15 ` Thomas Monjalon
2018-01-31 12:18 ` Neil Horman
2018-01-31 12:36 ` 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=20180122013417.GB5415@neilslaptop.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=john.mcnamara@intel.com \
--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).