> On Mar 10, 2017, at 10:41 AM, Stephen Hemminger <step...@networkplumber.org> > wrote: > > On Fri, 10 Mar 2017 16:22:49 +0000 > "Wiles, Keith" <keith.wi...@intel.com> wrote: > >>> On Mar 10, 2017, at 10:06 AM, Stephen Hemminger >>> <step...@networkplumber.org> wrote: >>> >>> On Fri, 10 Mar 2017 15:25:31 +0000 >>> "Wiles, Keith" <keith.wi...@intel.com> wrote: >>> >>>> I would like to request for comments on a new CLI design and get any >>>> feedback. I have attached the cli.rst text, which is still a work in >>>> progress for you review. >>>> >>>> I have also ported the CLI to a version of Pktgen on the ‘dev’ branch of >>>> the repo in DPDK.org. >>>> >>>> http://dpdk.org/browse/apps/pktgen-dpdk/refs/?h=dev >>>> >>>> I would like to submit the CLI library to be used in DPDK, if that seems >>>> reasonable to everyone. I need more testing of the API and Pktgen, but I >>>> feel it has a simpler design, easier to understand and hopefully make it >>>> easier for developers to add commands. >>>> >>>> As an example I quickly converted over testpmd from CMDLINE to CLI (I just >>>> add a -I option to select CLI instead) and reduced the test-pmd/cmdline.c >>>> file from 12.6K lines to about 4.5K lines. I did not fully test the code, >>>> but the ones I did test seem to work. >>>> >>>> I do not expect DPDK to convert to the new CLI only if it makes sense and >>>> I am not suggesting to replace CMDLINE library. >>>> >>>> If you play with the new CLI in pktgen and see any problems or want to >>>> suggest new features or changes please let me know. >>>> >>>> Comments on the cli.rst text is also welcome, but the cli.rst is not >>>> complete. I think this file needs to be broken into two one to explain the >>>> example and another to explain CLI internals. >>>> >>> >>> It would be great if all DPDK examples used a similar architecture. And >>> having a common >>> infrastructure would help. >>> >>> But not sure it needs to be special. Why should this be DPDK specific? >>> What you are building really ends up being an application >>> framework at some point. Surely, there are lots of others already in open >>> source. >>> >>> Heck even VPP has its own CLI inside. >> >> I have been looking for one for years and never found one that met my needs >> of easy to use and easy to understand. If you can find a better one then >> please let me know. >> >> This code does use some DPDK APIs but they can be removed to make it >> standalone and the first version I did was standalone. Some of the ones I >> found were similar to cmdline and some took it a step farther by trying to >> do everything one would ever need in a CLI. Those are way too big and >> difficult to use, then you have the ones that are barely a step above >> readline or just writing you own. The cmdline interface falls closer to the >> trying to do everything for you, by converting strings into values with >> structures/macros difficult to understand at a glance. IMHO this one is >> simple and easy to understand. >> >> But in truth the cmdline interface in DPDK is difficult to use and to write >> code for, takes way to many lines of code to make a simple command. The >> current Cmdline is also not dynamic, which makes it difficult to add >> features on the fly. >> >> All of the commands are at the same level and using a directory structure >> allows the developer to use what directory path he takes to denote a context >> for the command. As the example of converting test-pmd to use CLI the number >> of lines dropped from 12.6K to 4.5K lines. The cmdline code is also not >> consider to be production quality (from the docs) and I would like to fix >> that problem for DPDK. >> > > If you look beyond the simple C model there are a lot. > TCL > http://wanderinghorse.net/computing/shellish/eshell.html
I have looked at this one I believe and TCL is pretty big of a code base and not a fan of TCL in the first place :-) In VxWorks it used Tcl, which is good language to quickly write code, but not very friendly on a small memory machine in the case of embedded devices. This one is written in C++, which I am not again not a fan of C++ for these type of product. Also not a big C++ coder could be the other reason :-) > > Though these may not match what is needed. Agree that the current cmdline() > method is not suitable. Regards, Keith
