[cmaster-next] VTYSH behavior change and extract.pl elimination

Quentin Young qlyoung at cumulusnetworks.com
Thu Dec 8 20:32:30 EST 2016


Folks,

I've been doing some hacking on vtysh in an effort to clean it up and fix
some obscure bugs and less-than-sane interactions with daemons. Initially
my efforts were focused on getting vtysh to automatically update its
vty->node when a daemon node changes instead of needing a manual DEFUN
override for every such daemon command. I have this working; after
executing a command, the daemon side of the vty returns what node it is in
in addition to the command status code and any output, which vtysh uses to
update its own node. This in contrast to attempting to synchronize shared
state over the life of a vtysh session without actually communicating said
state.

That said, I think vtysh could use some more work on a slightly larger
scale. In my opinion extract.pl is fragile and error-prone. For example,
any command definitions outside the source files it looks in (such as the
default commands installed by lib/command.c) are not picked up and thus
need to be manually replicated in vtysh. Additionally anytime new submodes
are added, one has to remember to update extract.pl. And there are quite a
few edge cases that vtysh has to handle that ain't pretty.

I propose to change vtysh's behavior such that it no longer needs
compile-time knowledge of daemon CLI. Instead it should ask each daemon for
its CLI at runtime whenever needed, for example when a user types '?' or
hits tab. This has several benefits:

   - extract.pl can go away since vtysh no longer needs to know about
   daemon cli, and just implements CLI specific to itself
   - vtysh binary becomes ~93% smaller
   - problem of keeping vtysh in sync with daemons becomes trivial
   - daemons gain the ability to choose what CLI they expose
   - saves confusion caused by vtysh silently accepting CLI for which the
   appropriate daemon is not running
   - CLI for daemons which are not running is not shown

How to deal with this last point is probably the most important thing to
discuss because that is the change the user will see. Since vtysh will no
longer have foreknowledge of all CLI, it won't be able to distinguish
between a bogus command and a command that's valid but for which the daemon
is not running. I think this is an easy one to solve; we can just change

% Unknown command

to something like, for example,

% Unknown command (or daemon not running).

As mentioned above I see this as a benefit since it will prevent users
getting confused by vtysh silently accepting CLI for stopped daemons.

Feedback welcome.

Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20161208/99591838/attachment.html>


More information about the dev mailing list