From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by dpdk.org (Postfix) with ESMTP id 0E21858EE for ; Tue, 4 Nov 2014 00:17:46 +0100 (CET) Received: by mail-pa0-f47.google.com with SMTP id kx10so13155374pab.34 for ; Mon, 03 Nov 2014 15:27:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=tdqP8tUeQYHDl9kLlDRs+7K2fOgsKBgYsC15ZSOCcyM=; b=dwROxR4xQEhKuCoq5kQFsuj+6VYuFJ1HEpr33gkb2spql6oVEjyj4WxBH3G8C3FjNA i4B/rllikdAa7w/caoByZ4RSfsTP0NGTSDnNfmy/qP8zs2rIY3xGerx/fw1KKGQzgRbH thOJQCTwE9sGzaonyVH0ga59zCHh/qOMvUH4F8hN58i+KuiTzhMbRqEESVEQTCBs1srh +b4QtqNCpClNctY21F8Z9v0VhsHw4AFxNKOPYFSHcsmVhH1/MfAGrrHun48lbASCDPKQ m/SNr4gBSm8fEXuNDhqe0odJCLtlgnU3nrfthfbM84/rW4HwoyV8IBAvCmPe+StxFf24 L0MQ== X-Gm-Message-State: ALoCoQl5cNV7hR5rewdn13rsCkQPYOJc3tTW81qZZXOJw3qMNzBfWfCqffDRFhm7qUAILJtJ7px9 X-Received: by 10.70.45.72 with SMTP id k8mr4310942pdm.146.1415057222050; Mon, 03 Nov 2014 15:27:02 -0800 (PST) Received: from urahara (static-50-53-65-80.bvtn.or.frontiernet.net. [50.53.65.80]) by mx.google.com with ESMTPSA id of9sm18123119pbc.6.2014.11.03.15.26.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Nov 2014 15:27:01 -0800 (PST) Date: Mon, 3 Nov 2014 15:26:50 -0800 From: Stephen Hemminger To: "Wiles, Roger Keith" Message-ID: <20141103152650.262e4da3@urahara> In-Reply-To: <6F166021-567F-4B30-8EAE-EDB68A86C6CC@windriver.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] Add external parser support for unknown commands. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 23:17:47 -0000 On Mon, 3 Nov 2014 16:50:15 +0000 "Wiles, Roger Keith" wrote: >=20 > > On Nov 3, 2014, at 10:06 AM, Neil Horman wrote: > >=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 wrote: > >>>>=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 CMDLIN= E_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 char *= buy); > >>>>>>=20 > >>>>>> Signed-off-by: Keith Wiles > >>>>>=20 > >>>>> Hi Keith, > >>>>>=20 > >>>>> what is the expected use case for this? Is it for embedding other p= rogramming languages alongside the existing DPDK command-line or some other= purpose? [Perhaps the use case could be called out in the patch descriptio= n] > >>>>=20 > >>>> Hi Bruce, > >>>>=20 > >>>> I guess the external parser could be used for other programming lang= uages, but the case I was looking at was to provide a default escape from t= he command line parser to allow my application to handle the commands not u= nderstood by the parser. Now that you point it out I could use something li= ke =E2=80=98%=E2=80=99 to execute a single line of scr= ipt code, which is a good idea (thanks). > >>>>=20 > >>>> One case I am looking at is when you want to execute a command and d= o not want to add the support into the commands.c file for every possible c= ommand. Take the case where you have a bunch of scripts (Lua) in a director= y much like a bin directory. Then you could type foo.lua or foo on the comm= and 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 the builtin com= mands. > >>>>=20 > >>>> For Pktgen I had to add a command called =E2=80=98run =E2=80=99 to support running a script with arguments. I also ne= eded to add a argvlist type to cmdline to not error out on that command and= split up the args into a argv list like format. (Maybe I need to submit th= at code??) It seemed more straight forward to just pass the command line to= the application to run the command. I understand that seems like a minor p= oint, 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 something li= ke =E2=80=98run foo.lua=E2=80=99 or just =E2=80=98run foo=E2=80=99 and let = the code figure out what to run. I have more plans for this features as wel= l and have not finished the basic PoC yet. If you want a peek I can show yo= u what I am working on currently. > >>>>=20 > >>>> Does this help and do I really need to add all of this to the commit= message :-) > >>>>=20 > >>> Thanks for the explanation. However, if you are looking to have the a= pplication handle a bunch of commands itself, why does it need to use the c= ommandline library at all? Why not just have the app handle all the command= s instead of some of them? > >>=20 > >> I guess that would be reasonable, but then I would have to add support= 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 th= en just doing my own command line design. In the cmdline code you guys prov= ided is a lot of features like history, control key support, arg parsing (I= P, MAC) and many others. I would rather not have to write that code myself. > >>=20 > >> The default case is the same behavior today, with giving a no match er= ror unless they add the external parser. > >=20 > > It seems alot simpler than that to me. Looking at the test application= s, the > > command line parser expects the application to create an array of > > cmdline_parse_ctx_t structures to support new option parsing. If your = goal is > > to support other languages, it seems to make more sense to just use for= eign > > language bindings to merge your coding language support with the DPDK > > (ostensibly you will already have to do that if you want to use other p= arts 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 code is t= he right solution . In Pktgen I use Lua as the direct language binding 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 able to= execute say a line of script code is not really the requirement IMO. Being= able to extend the cmdline code with a default case is a good feature and = allows the developer to extend cmdline for some simple cases. The cmdline c= ode is kind of simple, but does require a fair amount of structures, code a= nd understanding to write a complex extendable command line interface. It d= oes 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 the l= anguage as I did with Lua and Pktgen. It could have been done with any lang= uage I just picked Lua, but the patch does not really add support for a lan= guage other then giving some support for someone to handle the no_match cas= e. >=20 > The use case for this feature is not just for Pktgen, but another solutio= n 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 pa= tch to add Lua with DPDK specific binding and extensions. (also allowing th= ose `other` languages too :-) Being able to use a scripting language and be= able to call DPDK API=E2=80=99s could be useful. How useful not sure at th= is time. (If you want to talk about this topic please start a new thread). > >=20 > > Am I missing something? > > Neil > >=20 > >=20 > >>>=20 > >>> /Bruce > >>=20 > >> Keith Wiles, Principal Technologist with CTO office, Wind River mobile= 972-213-5533 >=20 > Keith Wiles, Principal Technologist with CTO office, Wind River mobile 97= 2-213-5533 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 really is= n't very complete and flexible. Seems like the kind of thing that doesn't reall= y even need to be in DPDK. Better off being part of some other library.