[dpdk-dev] [RFC] Yet another option for DPDK options
Neil Horman
nhorman at tuxdriver.com
Sun Jun 5 02:19:46 CEST 2016
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.
>
More information about the dev
mailing list