> On Mar 26, 2018, at 8:59 AM, Gaëtan Rivet <gaetan.ri...@6wind.com> wrote:
>
> Hi Neil,
>
> On Mon, Mar 26, 2018 at 07:38:19AM -0400, Neil Horman wrote:
>> On Fri, Mar 23, 2018 at 07:45:03PM +0100, Gaetan Rivet wrote:
>>> Signed-off-by: Gaetan Rivet <gaetan.ri...@6wind.com>
>>> ---
>>>
>>> Cc: Neil Horman <nhor...@tuxdriver.com>
>>>
>
> Keep in mind that all of this is to achieve the trivial task I was
> doing in 20 lines or so.
>
>> I'm actually ok with this but as Keith noted, I'm not sure why you didn't
>> just:
>>
>> 1) Add the ability to create a grouping key, so that key value pairs could
>> contain a list of comma separated values (something like '{}' to denote that
>> everything between the characters was the value in a kv pair, regardless of
>> other tokenizing characters in the value).
>>
>> 2) Add the ability to recursively parse the value into a list of tokens
>>
>
> I don't need a recursive construct or a tree-like structure. I only need
> an alternative to '\0' to signify "end-of-list".
> This seems like an edge-case to librte_kvargs that would only be useful
> to a specific case. It does not seem a wise addition.
>
> So maybe I did not understand your suggestion. Can you give an example
> of inputs?
>
> I need to parse something like
>
> "bus=pci,vendor_id=0x8086/class=eth"
> (and I only care about bus=pci and class=eth).
>
> how can grouping help? My issue is that librte_kvargs would parse
>
> key:vendor_id
> value:0x8086/class
>
> and would then stumble on the unexpected '=‘.
Let me try to remember what I did here.
Created a new list structure of top level keywords like ‘bus’, ‘class’, …
The new list is passed into the new API that splits up the string by
‘/‘ then for each string you call into the original kvargs routines to parse
the remaining items within each string. I believe I passed a function pointer
in the new array of structures that allowed me to handle the top level
keywords. What is passed to the top level keyword function is the string to be
parsed by the normal kvargs routines. Each routine then used kvargs routines as
normal. I am sure the layer could be done differently and the structure could
maybe even contain the kvargs list or keywords if you want.
Anyway it worked out pretty well, just adding new APIs to handle and layer on
top of kvargs APIs.
>
>> 3) Layer your functionality on top of (1) and (2), as Keith noted
>
> The stack allocator seems like a nice-to-have that would interest
> people using librte_kvargs. I find librte_kvargs to be cumbersome. I
> cannot rewrite it from scratch, unless I update everything that relies
> on it as well. So I do not touch it, because I don't care *that* much.
>
> Why not simply leave my helper alongside? If people care enough about
> it and would prefer to use it over librte_kvargs, then maybe we could
> think about doing the effort of exposing it cleanly (or maybe they could).
> Right now, I see only me needing it and I do not see this effort as
> worth it.
>
> Regards,
> --
> Gaëtan Rivet
> 6WIND
Regards,
Keith
