[PATCH v4 0/7] document and simplify use of cmdline

[David Marchand]

On Tue, Oct 17, 2023 at 10:29 AM Bruce Richardson
<bruce.richardson at intel.com> wrote:
> >
> > - testpmd accepts both "help" and "help <section>" commands.
> > But the cmdline library does not provide a way (afair) for specifiying
> > this "optional" aspect.
> >
> > And it can't be expressed with this series current syntax since
> > generated symbols would conflict if we ask for two "help" commands.
> >
> > My quick hack was to introduce a way to select the prefix of the
> > generated symbols.
> > There may be a better way, like finding a better discriminant for
> > naming symbols...
> > But, on the other hand, the symbols prefix might be something a
> > developer wants to control (instead of currently hardcoded cmd_
> > prefix).
> >
> > @@ -20,6 +20,12 @@ def process_command(tokens, cfile, comment):
> >      """Generate the structures and definitions for a single command."""
> >      name = []
> >
> > +    prefix, sep, cmd_name = tokens[0].partition(':')
> > +    if cmd_name:
> > +        tokens[0] = cmd_name
> > +    else:
> > +        prefix = 'cmd'
> > +
> >      if tokens[0].startswith('<'):
> >          print('Error: each command must start with at least one
> > literal string', file=sys.stderr)
> >          sys.exit(1)
> >
> > (etc... I am not copying the rest of the diff)
> >
> > I then used as:
> >
> > cmd_brief:help # help: Show help
> > help <STRING>section # help: Show help
> >
>
> Interesting. I actually had no plans to even consider moving something like
> testpmd over. However, this is an interesting one, though I'm not really

Given the extensive use of the cmdline library in testpmd, it is a
good way to identify the limits of this series :-).


> sure I like it that much as a feature :-) I rather like having unique
> prefixes for each command. I wasn't actually aware of the testpmd "help
> <section>" command at all. I will have to look into it.

Let me propose an alternative hack.
I mentionned previously that we could have a better namespace /
discriminant for those symbols, and it seems easier than I thought:

@@ -25,8 +25,10 @@ def process_command(tokens, cfile, comment):
         sys.exit(1)
     for t in tokens:
         if t.startswith('<'):
-            break
-        name.append(t)
+            t_type, t_name = t[1:].split('>')
+            name.append(t_name)
+        else:
+            name.append(t)
     name = '_'.join(name)

     result_struct = []

With this, any command implementation symbol has the full chain of
token names as a prefix which will ensure there is no conflict.
WDYT?

help # help: Show help
help <STRING>section # help: Show help

Results in:

cmd_help_parsed(void *parsed_result, struct cmdline *cl, void *data);
struct cmd_help_result {
static cmdline_parse_token_string_t cmd_help_help_tok =
    TOKEN_STRING_INITIALIZER(struct cmd_help_result, help, "help");
static cmdline_parse_inst_t cmd_help = {
    .f = cmd_help_parsed,
        (void *)&cmd_help_help_tok,

And:

cmd_help_section_parsed(void *parsed_result, struct cmdline *cl, void *data);
struct cmd_help_section_result {
static cmdline_parse_token_string_t cmd_help_section_help_tok =
    TOKEN_STRING_INITIALIZER(struct cmd_help_section_result, help, "help");
static cmdline_parse_token_string_t cmd_help_section_section_tok =
    TOKEN_STRING_INITIALIZER(struct cmd_help_section_result, section, NULL);
static cmdline_parse_inst_t cmd_help_section = {
    .f = cmd_help_section_parsed,
        (void *)&cmd_help_section_help_tok,
        (void *)&cmd_help_section_section_tok,


>
> >
> > - Multi choice fixed strings is something that is often used in
> > testpmd, like here, in the help <section> command.
> > Here is my quick hack:
> >
> > diff --git a/buildtools/dpdk-cmdline-gen.py b/buildtools/dpdk-cmdline-gen.py
> > index 3b41fb0493..e8c9e079de 100755
> > --- a/buildtools/dpdk-cmdline-gen.py
> > +++ b/buildtools/dpdk-cmdline-gen.py
> > @@ -35,7 +35,11 @@ def process_command(tokens, cfile, comment):
> >      for t in tokens:
> >          if t.startswith('<'):
> >              t_type, t_name = t[1:].split('>')
> > -            t_val = 'NULL'
> > +            if len(t_type.split('(')) == 2:
> > +                t_type, t_val = t_type.split('(')
> > +                t_val = '"' + t_val.split(')')[0] + '"'
> > +            else:
> > +                t_val = 'NULL'
> >          else:
> >              t_type = 'STRING'
> >              t_name = t
> > @@ -113,7 +117,7 @@ def process_commands(infile, hfile, cfile, ctxname):
> >              continue
> >          if '#' not in line:
> >              line = line + '#'  # ensure split always works, even if
> > no help text
> > -        tokens, comment = line.split('#', 1)
> > +        tokens, comment = line.rsplit('#', 1)
> >          instances.append(process_command(tokens.strip().split(),
> > cfile, comment.strip()))
> >
> >      print(f'static __rte_used cmdline_parse_ctx_t {ctxname}[] = {{')
> >
> >
> > Which translates as:
> > cmd_brief:help # help: Show help
> > help <STRING(all#control#display#config#ports)>section # help: Show help
> >
>
> +1
> I was actualy thinking that adding support for multi-choice fixed strings
> is something we should add. One thought that I had was that "#" is not a
> particularly good choice of separator here. While, as you show, it can be
> made to work; I think - since we are defining our own syntax here - that it
> would be both simpler for the script, and simpler for the user, to have "|"
> as the option separator. It should be familiar for everyone as an option
> separator from regexes, unlike "#" which is more familar for comments.
>
> So what about:
> help <|all|control|display|config|ports|>section

I don't like using | as it gives the false impression regexp are supported...


>
> By starting with the separator, we should avoid having to provide the
> STRING type at all.

... and as a consequence, I find <|all confusing, it is like an empty
value would be acceptable.


About skipping the token type for such lists, I had considered it, but
I thought other types took an optional list of allowed values...
Now looking at the cmdline types, it is not the case.
Maybe I mixed with some other cli framework I played with in the past...

All of this to say, ok for me to omit the type.


>
> To my previous point on not liking to have a prefix-specifier, the
> alternative to making testpmd work with the script is to tweak very
> slightly the "help <section>".
>
>   help   # show general help
>   help on <|all|control|display|config|ports|>section
>
> By making the command "help on ports" rather than "help ports" we would
> avoid the need for the prefix syntax.

There are other cases where a "chain of command" returns the value of
a parameter.
And the same parameter may be set via "chain of command <UINT>value".


-- 
David Marchand