On 08/20/2013 02:30 PM, Eric Blake wrote: > I'm not a fan of this. We worked hard to get some commands (like 'virsh > echo') to NOT need a connection, and this would be undoing that work. I > think we should NOT autoconnect UNTIL we reach the point that completion > is being attempted on something where a connection is needed to get the > completer list, rather than this code which autoconnects regardless of > whether we need completion. Having 'virsh echo' avoid an autoconnect is > useful - it can be used to prove whether virsh itself is working or has > a problem such as a missing .so, without complicating the diagnosis with > a question of whether it is a bad default connection to blame. More along that line of thought: If I type: $ virsh virsh> e<TAB> I want a completion to list all commands that start with 'e'; one of those commands is 'echo', which does not need a connection. Therefore, if I use the shell: $ virsh e<TAB> and the shell uses, under the hood, $ virsh complete e that particular completion attempt should NOT attempt an autoconnect, because it is not completing on any information that requires a connection. autoconnect to qemu:///session can be noticeably time-consuming on the first time it is attempted. Although the session server tends to stick around for a few seconds after the last connection, so that future connection attempts in a short timeframe are serviced faster, you still don't want to pay the penalty for a delay for the first autoconnect until it is mandatory for the completion at hand. Whereas an interactive virsh keeps one connection open across multiple uses, the bash completion routines will be invoking a different instance of 'virsh' for every <TAB> hit on the shell command line, where we want each instance to be as fast as possible. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list