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 E45BE9FE for ; Mon, 11 Dec 2017 19:44:43 +0100 (CET) Received: from cpe-2606-a000-111b-423c-e874-da8e-c543-d863.dyn6.twc.com ([2606:a000:111b:423c:e874:da8e:c543:d863] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1eOT47-0006Id-PW; Mon, 11 Dec 2017 13:44:41 -0500 Date: Mon, 11 Dec 2017 13:44:03 -0500 From: Neil Horman To: Bruce Richardson Cc: dev@dpdk.org, Thomas Monjalon , "Mcnamara, John" Message-ID: <20171211184403.GD18284@hmswarspite.think-freely.org> References: <20171201185628.16261-1-nhorman@tuxdriver.com> <20171208171435.29875-1-nhorman@tuxdriver.com> <20171208171435.29875-4-nhorman@tuxdriver.com> <20171211113556.GA14772@bricha3-MOBL3.ger.corp.intel.com> <20171211124043.GA18284@hmswarspite.think-freely.org> <20171211124550.GD11536@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171211124550.GD11536@bricha3-MOBL3.ger.corp.intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCHv2 3/4] 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: Mon, 11 Dec 2017 18:44:44 -0000 On Mon, Dec 11, 2017 at 12:45:50PM +0000, Bruce Richardson wrote: > On Mon, Dec 11, 2017 at 07:40:43AM -0500, Neil Horman wrote: > > On Mon, Dec 11, 2017 at 11:35:57AM +0000, Bruce Richardson wrote: > > > On Fri, Dec 08, 2017 at 12:14:34PM -0500, 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 a > > > > ALLOW_EXPERIMENTAL_FUNCTIONS variable check to allow for in-tree dpdk > > > > libraries to override those checks. > > > > > > > > Signed-off-by: Neil Horman > > > > CC: Thomas Monjalon > > > > CC: "Mcnamara, John" > > > > --- > > > > > > Hi Neil, > > > > > > if I read the patch functionality correctly, the > > > ALLOW_EXPERIMENTAL_FUNCTIONS variable simply suppresses all errors for > > > deprecated functions. However, what we really want is just to suppress > > > the errors for the experimental functions, and not any that really are > > > deprecated. While we may not have any now in DPDK, that doesn't mean it > > > might not be useful to have some in future. > > > > > Well, they are all deprecated by the stict definition of the term, which is to > > say that their usage is discouraged/disapproved. What I think you are saying is > > that you would like to differentiate reasons for deprecation (i.e. deprecation > > because an api is experimental, vs deprecation because an api is broken or going > > to be removed). I'm not sure I see that we will get there anytime soon, but > > yes, that seems like it would be a good ability to add in here. > > > > > Therefore, would an alternative scheme work where the experimental tag > > > is set to empty if the ALLOW_EXPERIMENTAL_FUNCTIONS define is set when > > > compiling? > > > > > Yes, I think that could work. Perhaps what we can do is modify > > ALLOW_EXPERIMENTAL_FUNCTIONS to set a CFLAGS like: > > -DSUPPRESS_EXPERIMENTAL > > > > And use that to toggle the definition on rte_compat.h between something that > > deprecates the API call and an empty definition > > > > Yes, exactly what I was thinking, but failed to express so clearly. > > Also, would the flag be best set globally when building DPDK itself, > rather than changing individual makefiles per library? > My personal opinion would be that the ability to set allowances on a fine grained scale would be preferable to a global exception. I say that because I could envision a new library getting written in which the author would not want to use experimental APIS and would like the option to catch that during development. I would like to think that adding -DALLOW_EXPERIMENTAL_APIS to any new makefile in the DPDK build would be both little enough trouble to do without irritation, and significant enough of a bump during development as to force the developer to make a conscious choice about enabling experimental APIS. The idea here is not to prevent developers from using experimental APIS (especially not in the core dpdk library, as I noted previously), but to make them consciously choose to use them, rather than just do so out of hand. That said, I could be swayed if there was a sufficiently motivating reason to grant a global exception. Neil