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 AA114569F for ; Sun, 5 Jun 2016 02:20:01 +0200 (CEST) Received: from [107.15.76.160] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1b9LnB-0004Sy-7o; Sat, 04 Jun 2016 20:19:50 -0400 Date: Sat, 4 Jun 2016 20:19:46 -0400 From: Neil Horman To: Matthew Hall Cc: "Wiles, Keith" , Arnon Warshavsky , Panu Matilainen , "Richardson, Bruce" , Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Olivier Matz Message-ID: <20160605001946.GA8200@neilslaptop.think-freely.org> References: <8CE01283-1E89-4302-BE7D-486975B43EF6@intel.com> <20160603174437.GC12627@hmsreliant.think-freely.org> <62A67FEB-AE18-43B1-8D15-27F23D5C8A7D@intel.com> <20160603183819.GD12627@hmsreliant.think-freely.org> <20160603191804.GE12627@hmsreliant.think-freely.org> <20160603214137.GC16022@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160603214137.GC16022@mhcomputing.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -1.0 (-) X-Spam-Status: No Subject: Re: [dpdk-dev] [RFC] Yet another option for DPDK options X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 00:20:02 -0000 On Fri, Jun 03, 2016 at 02:41:37PM -0700, Matthew Hall wrote: > On Fri, Jun 03, 2016 at 03:18:04PM -0400, Neil Horman wrote: > > I'm not opposed to default values, but it seems to me that if we are splitting > > out a configuration storage library from dpdk, part of the initzliation of that > > library can be installing default values. That is to say, instead of having the > > code specific areas assume a default value if none is present in the config, an > > init function for the configuration storage library would just populate the > > keystore. That way all the dpdk itself has to do is a key lookup. > > > > Neil > > I don't think this provides as much mental locality of reference for people > reading the code. But, an unwanted default argument can be filled with 0 / > NULL / false as needed. > Well, I'm operating under the assumption that default values are used in cases where a lack of any value (i.e. the unset case), creates a state in DPDK where it cannot continue (i.e. it would crash). If a unset state is for some reason required on a key that is otherwise populated with a default, then I would propose that an UnsetKey api call be added. Neil > Matthew. >