From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [PATCH] Add external parser support for unknown commands. Date: Mon, 3 Nov 2014 18:42:30 -0500 Message-ID: <20141103234230.GA2660@localhost.localdomain> References: <1414967308-69530-1-git-send-email-keith.wiles@windriver.com> <20141103104129.GA4840@bricha3-MOBL3> <307F2C60-7638-40C8-A9BC-DC3EE3D59F8C@windriver.com> <20141103141658.GA6964@bricha3-MOBL3> <7D39110F-D305-4C48-8BD6-37F6DCD2E434@windriver.com> <20141103160602.GA6625@localhost.localdomain> <6F166021-567F-4B30-8EAE-EDB68A86C6CC@windriver.com> <20141103152650.262e4da3@urahara> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Stephen Hemminger Return-path: Content-Disposition: inline In-Reply-To: <20141103152650.262e4da3@urahara> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On Mon, Nov 03, 2014 at 03:26:50PM -0800, Stephen Hemminger wrote: > On Mon, 3 Nov 2014 16:50:15 +0000 > "Wiles, Roger Keith" wrote: >=20 > >=20 > > > On Nov 3, 2014, at 10:06 AM, Neil Horman wr= ote: > > >=20 > > > On Mon, Nov 03, 2014 at 02:25:51PM +0000, Wiles, Roger Keith wrote: > > >>=20 > > >>> On Nov 3, 2014, at 8:16 AM, Bruce Richardson wrote: > > >>>=20 > > >>> On Mon, Nov 03, 2014 at 02:08:46PM +0000, Wiles, Roger Keith wrot= e: > > >>>>=20 > > >>>>> On Nov 3, 2014, at 4:41 AM, Bruce Richardson wrote: > > >>>>>=20 > > >>>>> On Sun, Nov 02, 2014 at 04:28:28PM -0600, Keith Wiles wrote: > > >>>>>> Allow for a external parser to handle the command line if the > > >>>>>> command is not found and the developer has called the routine > > >>>>>> int cmdline_set_external_parser(struct cmdline * cl, > > >>>>>> cmdline_external_parser_t parser)= ; > > >>>>>> function to set the function pointer. > > >>>>>>=20 > > >>>>>> The function for the external parser function should return CM= DLINE_PARSE_NOMATCH > > >>>>>> if not able to match the command requested or zero is handled. > > >>>>>>=20 > > >>>>>> Prototype of external routine: > > >>>>>> int (*cmdline_external_parser_t)(struct cmdline * cl, const ch= ar * buy); > > >>>>>>=20 > > >>>>>> Signed-off-by: Keith Wiles > > >>>>>=20 > > >>>>> Hi Keith, > > >>>>>=20 > > >>>>> what is the expected use case for this? Is it for embedding oth= er programming languages alongside the existing DPDK command-line or some= other purpose? [Perhaps the use case could be called out in the patch de= scription] > > >>>>=20 > > >>>> Hi Bruce, > > >>>>=20 > > >>>> I guess the external parser could be used for other programming = languages, but the case I was looking at was to provide a default escape = from the command line parser to allow my application to handle the comman= ds not understood by the parser. Now that you point it out I could use so= mething like =E2=80=98%=E2=80=99 to execute a single= line of script code, which is a good idea (thanks). > > >>>>=20 > > >>>> One case I am looking at is when you want to execute a command a= nd do not want to add the support into the commands.c file for every poss= ible command. Take the case where you have a bunch of scripts (Lua) in a = directory much like a bin directory. Then you could type foo.lua or foo o= n the command line and execute the foo.lua having the application detect = you want to load and run a Lua script after it has finished parsing for t= he builtin commands. > > >>>>=20 > > >>>> For Pktgen I had to add a command called =E2=80=98run = =E2=80=99 to support running a script with arguments. I a= lso needed to add a argvlist type to cmdline to not error out on that com= mand and split up the args into a argv list like format. (Maybe I need to= submit that code??) It seemed more straight forward to just pass the com= mand line to the application to run the command. I understand that seems = like a minor point, but it does make it easier to use and to support the = features I want to support in my PoC. > > >>>>=20 > > >>>> Using this method you can just type the name instead of somethin= g like =E2=80=98run foo.lua=E2=80=99 or just =E2=80=98run foo=E2=80=99 an= d let the code figure out what to run. I have more plans for this feature= s as well and have not finished the basic PoC yet. If you want a peek I c= an show you what I am working on currently. > > >>>>=20 > > >>>> Does this help and do I really need to add all of this to the co= mmit message :-) > > >>>>=20 > > >>> Thanks for the explanation. However, if you are looking to have t= he application handle a bunch of commands itself, why does it need to use= the commandline library at all? Why not just have the app handle all the= commands instead of some of them? > > >>=20 > > >> I guess that would be reasonable, but then I would have to add sup= port for all of the command line parsing being done in the cmdline code. = Think of this as a default case for the parser and to me that makes more = sense then just doing my own command line design. In the cmdline code you= guys provided is a lot of features like history, control key support, ar= g parsing (IP, MAC) and many others. I would rather not have to write tha= t code myself. > > >>=20 > > >> The default case is the same behavior today, with giving a no matc= h error unless they add the external parser. > > >=20 > > > It seems alot simpler than that to me. Looking at the test applica= tions, the > > > command line parser expects the application to create an array of > > > cmdline_parse_ctx_t structures to support new option parsing. If y= our goal is > > > to support other languages, it seems to make more sense to just use= foreign > > > language bindings to merge your coding language support with the DP= DK > > > (ostensibly you will already have to do that if you want to use oth= er parts of > > > the DPDK). > > Hi Neil, > >=20 > > A true language binding like Lua or one of those other languages :-) = you are correct to believe binding directly using =E2=80=98C=E2=80=99 cod= e is the right solution . In Pktgen I use Lua as the direct language bind= ing and extend Lua with specific Pktgen functions. > >=20 > > What I am doing here is to add a default case to cmdline code, which = just happens to allow me to parse the cmdline in the application. Being a= ble to execute say a line of script code is not really the requirement IM= O. Being able to extend the cmdline code with a default case is a good fe= ature and allows the developer to extend cmdline for some simple cases. T= he cmdline code is kind of simple, but does require a fair amount of stru= ctures, code and understanding to write a complex extendable command line= interface. It does seem hard to find a clean, simple and usable embedded= command line code base is not very easy to locate.=20 > >=20 > > Adding a true language binding really requires using code to extend t= he language as I did with Lua and Pktgen. It could have been done with an= y language I just picked Lua, but the patch does not really add support f= or a language other then giving some support for someone to handle the no= _match case. > >=20 > > The use case for this feature is not just for Pktgen, but another sol= ution I hope everyone will find useful when I get it more complete. > >=20 > > Thanks > > ++Keith > >=20 > > PS. on a different topic I was thinking about suggesting and writing = a patch to add Lua with DPDK specific binding and extensions. (also allow= ing those `other` languages too :-) Being able to use a scripting languag= e and be able to call DPDK API=E2=80=99s could be useful. How useful not = sure at this time. (If you want to talk about this topic please start a n= ew thread). > > >=20 > > > Am I missing something? > > > Neil > > >=20 > > >=20 > > >>>=20 > > >>> /Bruce > > >>=20 > > >> Keith Wiles, Principal Technologist with CTO office, Wind River mo= bile 972-213-5533 > >=20 > > Keith Wiles, Principal Technologist with CTO office, Wind River mobil= e 972-213-5533 >=20 > I wouldn't invest a lot of sweat in the command line parser. > The one in the DPDK is "good enough" for what it needs to do, but reall= y isn't > very complete and flexible. Seems like the kind of thing that doesn't r= eally even > need to be in DPDK. Better off being part of some other library. >=20 Well, something needs to be there to parse the libraries' common options,= though I agree, making eal_cmdline just a registration frontend to getopt or getopt_long would be sufficient. Neil