Patch Set 3:

(2 comments)

re "you don't mention duplicate avoidance" -- is that asking to improve the 
commit log? agreed.

https://gerrit.osmocom.org/#/c/3979/3/src/vty/command.c
File src/vty/command.c:

Line 158:       if (!*node->name)
> use node->name[0]? But why derive it from the prompt? It seems like an inte
node->name is a char[], and if it is unset, it starts with 0 as from struct 
initialization. Hence an unset node->name means !*node->name.

Derive it from the prompt: we have a node struct that defines the node ID, a 
prompt and a write cb, and its commands. The way we enter this node though is 
not tied to this struct at all. At some other node there is this "arbitrary" 
vty command that decides: now let's go to this node. My first idea is to try to 
derive the node name from the command that enters it, but it is impossible to 
find out.

        static struct cmd_node msc_node = {
                MSC_NODE,
                "%s(config-msc)# ",
                1,
        };

        DEFUN(cfg_msc, cfg_msc_cmd,
              "msc", "Configure MSC options")
        {
                vty->node = MSC_NODE;
                return CMD_SUCCESS;
        }

        install_element(CONFIG_NODE, &cfg_msc_cmd);

>From msc_node, it is impossible to find out that cfg_msc_cmd which entered the 
>MSC_NODE is in fact called 'msc'.

The next idea is that each cmd_node struct that is created should provide a 
node name like:

        static struct cmd_node msc_node = {
                MSC_NODE,
                "%s(config-msc)# ",
                1,
                .name = "config-msc",
        };

but none of your current users of the VTY API do that. We would start off with 
most nodes being unnamed and it would take some time to find all of them. The 
nice way would be to define a name, and let the prompt be derived from that.

But for hysterical raisins, it is easier to go the other way: all of our nodes 
have a prompt, and by stripping the special prompt characters we can get a 
fairly unique name from it without touching any of the dependent code.


Line 612:               same_name_count = 1;
> Why start with 1? For the first node it has not used before?
The idea is to get IDs like

  name
  name_2
  name_3

i.e. the first is just the name, the second gets _2 attached. When I start 
searching, I know that one 'name' already exists, if I find another one I know 
that 2 exist.

I considered starting with 0, but don't like the result like:

  name
  name_1
  name_2

nor

  name_0
  name_1
  name_2

The _2 suffix is just to make sure we number multiple occurences and should 
normally not happen. It also is a fallback for empty node names, they will 
become

  _1
  _2
  _3
  ...


-- 
To view, visit https://gerrit.osmocom.org/3979
To unsubscribe, visit https://gerrit.osmocom.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I8fa555570268b231c5e01727c661da92fad265de
Gerrit-PatchSet: 3
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <[email protected]>
Gerrit-Reviewer: Holger Freyther <[email protected]>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Neels Hofmeyr <[email protected]>
Gerrit-HasComments: Yes

Reply via email to