From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [PATCH] Add external parser support for unknown commands. Date: Mon, 3 Nov 2014 14:16:58 +0000 Message-ID: <20141103141658.GA6964@bricha3-MOBL3> References: <1414967308-69530-1-git-send-email-keith.wiles@windriver.com> <20141103104129.GA4840@bricha3-MOBL3> <307F2C60-7638-40C8-A9BC-DC3EE3D59F8C@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: "Wiles, Roger Keith" Return-path: Content-Disposition: inline In-Reply-To: <307F2C60-7638-40C8-A9BC-DC3EE3D59F8C-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org> 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 02:08:46PM +0000, Wiles, Roger Keith wrote: >=20 > > On Nov 3, 2014, at 4:41 AM, Bruce Richardson wrote: > > > > 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. > >> > >> The function for the external parser function should return CMDLINE_= PARSE_NOMATCH > >> if not able to match the command requested or zero is handled. > >> > >> Prototype of external routine: > >> int (*cmdline_external_parser_t)(struct cmdline * cl, const char * b= uy); > >> > >> Signed-off-by: Keith Wiles > > > > Hi Keith, > > > > what is the expected use case for this? Is it for embedding other pro= gramming languages alongside the existing DPDK command-line or some other= purpose? [Perhaps the use case could be called out in the patch descript= ion] >=20 > Hi Bruce, >=20 > I guess the external parser could be used for other programming languag= es, but the case I was looking at was to provide a default escape from th= e command line parser to allow my application to handle the commands not = understood by the parser. Now that you point it out I could use something= like =E2=80=98%=E2=80=99 to execute a single line o= f script code, which is a good idea (thanks). >=20 > One case I am looking at is when you want to execute a command and do n= ot want to add the support into the commands.c file for every possible co= mmand. Take the case where you have a bunch of scripts (Lua) in a directo= ry much like a bin directory. Then you could type foo.lua or foo on the c= ommand line and execute the foo.lua having the application detect you wan= t to load and run a Lua script after it has finished parsing for the buil= tin 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 also neede= d 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 t= hat 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 mi= nor 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 something like = =E2=80=98run foo.lua=E2=80=99 or just =E2=80=98run foo=E2=80=99 and let t= he code figure out what to run. I have more plans for this features as we= ll and have not finished the basic PoC yet. If you want a peek I can show= you what I am working on currently. >=20 > Does this help and do I really need to add all of this to the commit me= ssage :-) > Thanks for the explanation. However, if you are looking to have the appli= cation handle a bunch of commands itself, why does it need to use the com= mandline library at all? Why not just have the app handle all the command= s instead of some of them? /Bruce