From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mhall@mhcomputing.net>
Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170])
 by dpdk.org (Postfix) with ESMTP id 1C02247D0
 for <dev@dpdk.org>; Fri,  3 Jun 2016 23:38:49 +0200 (CEST)
Received: by mail.mhcomputing.net (Postfix, from userid 1000)
 id 3FE14D7; Fri,  3 Jun 2016 14:38:48 -0700 (PDT)
Date: Fri, 3 Jun 2016 14:38:48 -0700
From: Matthew Hall <mhall@mhcomputing.net>
To: Arnon Warshavsky <arnon@qwilt.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
 "Wiles, Keith" <keith.wiles@intel.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: <20160603213848.GA16022@mhcomputing.net>
References: <20160603110129.GB17812@bricha3-MOBL3>
 <20160603115048.GA12627@hmsreliant.think-freely.org>
 <CAKy9EB3ddPJo6qb6+WDiSb7aXdM61b0Sh1aQa5YrZE1s10hJdw@mail.gmail.com>
 <f7262fa6-220e-0050-1a06-b046ab9009df@redhat.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKy9EB2imz7S6h_UY2U9_V9iU5mvncfQRb3RGs+Uz9+ct5_10Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Fri, 03 Jun 2016 21:38:49 -0000

On Fri, Jun 03, 2016 at 09:52:40PM +0300, Arnon Warshavsky wrote:
> What about the data types of the values?
> I would assume that as a library it can provide the service of typed
> get/set and not leave conversion and validation to the app.
> 
> rte_map_get_int(map,section,key)
> rte_map_get_double(...)
> rte_map_get_string(...)
> rte_map_get_bytes(...,destBuff , destBuffSize) //e.g byte array of RSS key
> 
> This may also allow some basic validity of the configuration file
> 
> Another point I forgot about is default values.
> We sometimes use a notation where the app also specifies a default value in
> case the configuration did not specify it
>   rte_map_get_int(map,section,key , defaultValue )
> and specify if this was a mandatory that has no default
>   rte_map_get_int_crash_if_missing (map,section,key)

This is why I was advising to use something similar to json-c's API with some 
type specific functions to make things easier for the users, with the 
dot-terminated naming made popular by sysctl such as 
"debug.intel.ctr_KMD_CTR_RPUPEI" and so forth.

> /Arnon

Matthew