Regards,
Keith
On 6/1/16, 10:46 AM, "Matthew Hall" <mhall at mhcomputing.net> wrote:
>On Wed, Jun 01, 2016 at 03:00:11PM +0000, Wiles, Keith wrote:
>> The INI file is too flat and I wanted a hierarchy in the data, the JSON data
>> is similar and XML is just hard to read.
>
>I don't think it's fair to say JSON lacks hierarchy. Personally it is working
>great in my current application. The main "bug" is that the spec designers
>intentionally and idiotically left out the ability to make comments. But there
>are some smarter JSON parsers such as json-c and the Perl JSON parser which
>will allow them using either "#" or "//".
JSON-C could work and Lua has its comments too. I just wanted more from the
configuration then just data. You still need some code to parse the JSON format
in the application, right?
>
>You can also build JSON in memory pretty nicely using json-c. It has a simple
>DOM-like API for this.
>
>I am using it in the config file for my app right now, and passing a fake argc
>and argv to DPDK using wordexp() to prevent it from munging the argc and argv
>of my application.
>
>> It would be nice to execute a DPDK applications like this:
>>
>> ./some_dpdk_app ???config-file dpdk-config-filename
>
>FYI, I think you used Outlook with some of MS's bad defaults and it mangled
>all your special characters...
Yes, I hate MS Outlook. I have tried to fix the options, but it never seems to
work out. Until someone create a really good email application for OS X that
works with exchange I will stuck with this one. I have tried a number of
different ones, they all have limitations or problems ?
>
>> The dpdk-config-filename could contain a lot of information and be able to
>> startup multiple different applications. The dpdk-config-file could also
>> include other config files to complete the configuration. The format of the
>> data in the config file needs to be readable, but allow the user to put in
>> new options, needs to be hierarchical in nature and have some simple
>> functions to execute if required.
>
>To me, this is way too complicated and includes a lot of features I'm not
>convinced we actually need or want. I'd really prefer if we just have one file
>per app. I don't want a super complicated way to configure it replacing an
>already super complicated way to configure it.
I do not see it being too complexed I think it is what you have used before and
not that it is to complex of a solution.
>
>> The solution I was thinking is the file information is really just a
>> fragment of a scripting language, which the DPDK application contains this
>> scripting language interpreter. I was looking at using Lua lua.org as the
>> scripting language interpreter it is small and easy to understand.
>
>If we're stuck doing this Lua is the best option but I'd still rather avoid
>it. I like the fact that DPDK is a lot of clean C code, this is why I find it
>so much easier to read and code than the awful kernel network stacks.
We do not need to understand Lua interpreter or compiler only the simple Lua
scripting code.
>
>> lcore_list = mk_lcore_list("0-7", 10, "14-16"),
>> coremap = mk_coremap("(0-7)@0,10,(14-16)@1"),
>
>These magical functions feel weird compared to just having some simple
>functions that take them as JSON strings and validate them. Which is what I'm
>doing in my app right now with minimal pain.
These are just examples to convert to tables from strings and could have not
used them.
>
>> The EAL, driver, application, ??? would query an API to access the data and
>> the application can change his options quickly without modifying the code.
>
>I don't want to have to use somebody else's API to get to the config of my app
>if I can avoid it. I like the approach of json-c where I can lay it out how I
>want, and pass the parts I want DPDK to have over to DPDK. I don't necessarily
>want to have to go through DPDK to get to my own config stuff. Which is what I
>am stuck doing if we put a weird proprietary DPDK specific file format or
>scripting environment in these files.
Not sure the meaning of someone else?s API, we already have a difficult
configuration structure and command line interface, just trying to create a
common set up database like APIs to access the data. Now maybe JSON-c has some
already I do not know. Removing the command line options for just one option ?
seems like a good thing.
>
>> Keith
>
>Matthew.
>
