DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Wiles, Roger Keith" <keith.wiles@windriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] Add external parser support for unknown commands.
Date: Mon, 3 Nov 2014 14:16:58 +0000	[thread overview]
Message-ID: <20141103141658.GA6964@bricha3-MOBL3> (raw)
In-Reply-To: <307F2C60-7638-40C8-A9BC-DC3EE3D59F8C@windriver.com>

On Mon, Nov 03, 2014 at 02:08:46PM +0000, Wiles, Roger Keith wrote:
> 
> > On Nov 3, 2014, at 4:41 AM, Bruce Richardson <bruce.richardson@intel.com> 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 * buy);
> >>
> >> Signed-off-by: Keith Wiles <keith.wiles@windriver.com>
> >
> > Hi Keith,
> >
> > what is the expected use case for this? Is it for embedding other programming languages alongside the existing DPDK command-line or some other purpose? [Perhaps the use case could be called out in the patch description]
> 
> Hi Bruce,
> 
> 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 commands not understood by the parser. Now that you point it out I could use something like ‘%<line-of-script-code>’ to execute a single line of script code, which is a good idea (thanks).
> 
> One case I am looking at is when you want to execute a command and do not want to add the support into the commands.c file for every possible 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 on 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 the builtin commands.
> 
> For Pktgen I had to add a command called ‘run <filename> <args…>’ to support running a script with arguments. I also needed 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 that 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 point, but it does make it easier to use and to support the features I want to support in my PoC.
> 
> Using this method you can just type the name instead of something like ‘run foo.lua’ or just ‘run foo’ and let the code figure out what to run. I have more plans for this features as well and have not finished the basic PoC yet. If you want a peek I can show you what I am working on currently.
> 
> Does this help and do I really need to add all of this to the commit message :-)
>
Thanks for the explanation. However, if you are looking to have the 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?

/Bruce

  reply	other threads:[~2014-11-03 14:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-02 22:28 Keith Wiles
2014-11-03 10:41 ` Bruce Richardson
2014-11-03 14:08   ` Wiles, Roger Keith
2014-11-03 14:16     ` Bruce Richardson [this message]
2014-11-03 14:25       ` Wiles, Roger Keith
2014-11-03 16:06         ` Neil Horman
2014-11-03 16:50           ` Wiles, Roger Keith
2014-11-03 23:26             ` Stephen Hemminger
2014-11-03 23:42               ` Neil Horman
2014-11-04  4:52                 ` Wiles, Roger Keith
2014-11-04 11:27                   ` Neil Horman
2014-11-04 14:44                     ` Wiles, Roger Keith
2014-11-04 19:29                       ` Neil Horman
2014-11-04 20:45                         ` Wiles, Roger Keith
2014-11-05 15:11                           ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141103141658.GA6964@bricha3-MOBL3 \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=keith.wiles@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).