From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170]) by dpdk.org (Postfix) with ESMTP id D823519F5 for ; Fri, 3 Jun 2016 04:17:05 +0200 (CEST) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id 5AD91F5; Thu, 2 Jun 2016 19:17:05 -0700 (PDT) Date: Thu, 2 Jun 2016 19:17:05 -0700 From: Matthew Hall To: Neil Horman Cc: "Wiles, Keith" , Thomas Monjalon , Yuanhan Liu , "dev@dpdk.org" , "Richardson, Bruce" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Message-ID: <20160603021705.GA26580@mhcomputing.net> References: <20160602104106.GA12923@hmsreliant.think-freely.org> <2363376.b1CWhBpcZG@xps13> <75917C44-9CF7-4A0B-B8D3-CD7DC7425D49@intel.com> <20160602171120.GB12923@hmsreliant.think-freely.org> <7091836E-B9D5-4F99-ADDB-A47B4C7B5F7E@intel.com> <20160602200837.GC12923@hmsreliant.think-freely.org> <20160602205355.GB24543@mhcomputing.net> <20160602223458.GA24257@neilslaptop.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160602223458.GA24257@neilslaptop.think-freely.org> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 02:17:06 -0000 On Thu, Jun 02, 2016 at 06:34:58PM -0400, Neil Horman wrote: > > This sort of code is very 1970s / ioctl / messy binary. And doesn't buy any > > performance advantage because it's just for config. > > > What!? I can't even parse that sentence. I would not want to have to use the structure you proposed in user-readable code. It looked a lot like ugly ioctl stuff and I found the sysctl style interface easier to read. I don't see why that would be hard for anyone to parse but nevertheless. > > https://www.freebsd.org/cgi/man.cgi?sysctl(3) > > > I can't even begin to understand what you're after here. sysctl provides a > heirarchy in _exactly_ the same way that I just proposed, by texual consistency > in naming. I didn't object to the hierarchy part, but the user hostility of the example proposed. > > http://json-c.github.io/json-c/json-c-0.12/doc/html/json__object_8h.html > > > So, this is a fine interface to convert text config to a code format, but thats > a decision that application should be making, not something dpdk should mandate You're thinking way too narrowly here for what I am working to convey. I wasn't meaning to say JSON had to be used. I was saying, the kind of lightweight object-based API they used for modeling JSON has worked very well for modeling config data inside of my app. IE, simple functions for working with the following sort of entities (which are used in many file / interchange systems like JSON, MsgPack, YAML, etc.): Objects: * hashes, arbitrarily nested * arrays, arbitrarily nested Atoms: * strings - textual * strings - binary (something we should add for DPDK) * integers * floats / doubles * booleans In general I am seeing two good approaches for nesting: 1. name nesting like MIB variable "x.y.z.a.b.c" - this is how sysctl works 2. object nesting- this is how JSON, YAML, MsgPack, INI (implicitly w/ section names), XML etc. work... to express this in the Python / Ruby / JS style syntax it would be: config['x']['y']['z']['a']['b']['c'] using json-c it would be like json_object_object_get()... until a json_object_TYPE_get(). What I've done for these in the past, is to make something that can parse the sysctl-style name x.y.z.0.a.b.c, detect if each dotted-item is a string, in which case reach inside the dict for the string or return NULL if not found, and if it's a number reach inside the array for that index and return NULL if not found. Here is a Python example how to take the sysctl style and look it up inside some objects. The same thing could be done using anything with at least as rich of features as what json-c provides... RE_IS_INT = re.compile('^[0-9]+$') def retrieve_path(data, path): if isinstance(path, basestring): path = path.split('.') if isinstance(data, Mapping): result = data.get(path[0]) else: if not RE_IS_INT.match(str(path[0])): return None i = int(path[0]) result = data[i] if len(data) > i else None if len(path) == 1: return result else: if result: return fetch(result, path[1:]) else: return None > Neil Matthew