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