On Tue, Oct 17, 2023 at 10:29 AM Bruce Richardson
<bruce.richard...@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
