On Thu, Jun 02, 2016 at 07:17:05PM -0700, Matthew Hall wrote: > 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. > I still don't understand how you are likening a typed variable length array to an ioctl that uses unsigned long a single all encompasing argument, or how you see a difference between the ASN.1 style naming that sysctl uses and the ASN.1 style naming that I proposed. But I suppose thats neither here nor there, we can agree to disagree on those points.
> > > 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. > I take issue with that, I fail to see anything hostile about variable length arrays of unioned types. And if it iss to much, wrap a get/set api around it, which I would expect anyway to ease lookup tasks. > > > 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(). > soo, you want to borrow a parsing api for the sole purpose of using it as an in-memory configuration mechanism? I suppose thats fine, but as Bruce points out in his note, the dpdk already has an api that can be repurposed for that use. > 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 > That seems....500% more complicated than what dpdk really needs. All it really needs is key/value storage, with some minor semblance of a grouping mechanism, and the abiilty to store some basic types (void * at a minimum). The caller should know implicitly based on the key lookup/set what the type of the value is. The API could be as simple as: int setkey(char *key, void *value); void *getkey(char *key); void delkey(char *key); It could be more complex of course, but at a minuimum, thats really enough, if you didn't just want to expose a data structure to directly alter. Neil > Matthew >