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 '='.
> 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
