Even though I asked Quentin to send this email, I'd like to put a +1 on it. Let's think about modifying vtysh to ask running daemons what their command set is. donald On Thu, Dec 8, 2016 at 8:32 PM, Quentin Young <qlyoung@cumulusnetworks.com> wrote:
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
_______________________________________________ cmaster-next mailing list cmaster-next@lists.nox.tf https://lists.nox.tf/listinfo/cmaster-next