From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nhorman@tuxdriver.com>
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
 by dpdk.org (Postfix) with ESMTP id AA114569F
 for <dev@dpdk.org>; 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 <nhorman@tuxdriver.com>)
 id 1b9LnB-0004Sy-7o; Sat, 04 Jun 2016 20:19:50 -0400
Date: Sat, 4 Jun 2016 20:19:46 -0400
From: Neil Horman <nhorman@tuxdriver.com>
To: Matthew Hall <mhall@mhcomputing.net>
Cc: "Wiles, Keith" <keith.wiles@intel.com>, Arnon Warshavsky <arnon@qwilt.com>,
 Panu Matilainen <pmatilai@redhat.com>,
 "Richardson, Bruce" <bruce.richardson@intel.com>,
 Thomas Monjalon <thomas.monjalon@6wind.com>,
 Yuanhan Liu <yuanhan.liu@linux.intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
 "Tan, Jianfeng" <jianfeng.tan@intel.com>,
 Stephen Hemminger <stephen@networkplumber.org>,
 Christian Ehrhardt <christian.ehrhardt@canonical.com>,
 Olivier Matz <olivier.matz@6wind.com>
Message-ID: <20160605001946.GA8200@neilslaptop.think-freely.org>
References: <CAKy9EB3ca+nufggexRogY3TOU=LMdf1dRFJSPxhmdrdyW2fc6A@mail.gmail.com>
 <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>
 <CAKy9EB2imz7S6h_UY2U9_V9iU5mvncfQRb3RGs+Uz9+ct5_10Q@mail.gmail.com>
 <DC0EC027-2812-4D4F-A757-AB737999ACD4@intel.com>
 <AA73B345-1FBD-44CE-BD93-8B85D8DC9650@intel.com>
 <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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.
>