Re: [RFC] Yet another option for DPDK options

[Neil Horman <nhorman@tuxdriver.com>]

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.
>