From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id A2366A49A for ; Thu, 11 Jan 2018 21:50:43 +0100 (CET) Received: from [107.15.66.59] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1eZjnu-0000VW-HQ; Thu, 11 Jan 2018 15:50:39 -0500 Date: Thu, 11 Jan 2018 15:50:25 -0500 From: Neil Horman To: Ferruh Yigit Cc: dev@dpdk.org, thomas@monjalon.net, john.mcnamara@intel.com, bruce.richardson@intel.com Message-ID: <20180111205025.GA6879@hmswarspite.think-freely.org> References: <20171201185628.16261-1-nhorman@tuxdriver.com> <20171213151728.16747-1-nhorman@tuxdriver.com> <20171213151728.16747-4-nhorman@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCHv4 3/5] Makefiles: Add experimental tag check and warnings to trigger on use X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 20:50:43 -0000 On Thu, Jan 11, 2018 at 08:06:43PM +0000, Ferruh Yigit wrote: > On 12/13/2017 3:17 PM, Neil Horman wrote: > > Add checks during build to ensure that all symbols in the EXPERIMENTAL > > version map section have __experimental tags on their definitions, and > > enable the warnings needed to announce their use. Also add an > > ALLOW_EXPERIMENTAL_APIS define to allow individual libraries and files > > to declare the acceptability of experimental api usage > > > > Signed-off-by: Neil Horman > > CC: Thomas Monjalon > > CC: "Mcnamara, John" > > CC: Bruce Richardson > > --- > > app/test-eventdev/Makefile | 1 + > > app/test-pmd/Makefile | 1 + > > drivers/event/sw/Makefile | 1 + > > drivers/net/failsafe/Makefile | 1 + > > drivers/net/ixgbe/Makefile | 1 + > > examples/eventdev_pipeline_sw_pmd/Makefile | 1 + > > examples/flow_classify/Makefile | 1 + > > examples/ipsec-secgw/Makefile | 1 + > > examples/service_cores/Makefile | 1 + > > lib/librte_eal/bsdapp/eal/Makefile | 1 + > > lib/librte_eal/linuxapp/Makefile | 2 ++ > > lib/librte_eal/linuxapp/eal/Makefile | 2 ++ > > lib/librte_eventdev/Makefile | 1 + > > lib/librte_security/Makefile | 1 + > > mk/internal/rte.compile-pre.mk | 4 ++++ > > mk/toolchain/clang/rte.vars.mk | 2 +- > > mk/toolchain/gcc/rte.vars.mk | 2 +- > > mk/toolchain/icc/rte.vars.mk | 2 +- > > 18 files changed, 23 insertions(+), 3 deletions(-) > > > > diff --git a/app/test-eventdev/Makefile b/app/test-eventdev/Makefile > > index dcb2ac476..78bae7633 100644 > > --- 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. > 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. Regards Neil > > CFLAGS += -O3 > > CFLAGS += $(WERROR_FLAGS) > > > > <...> > >