[libvirt] [PATCH] virsh: add custom readline generator

Eric Blake eblake at redhat.com
Mon Jun 27 19:39:42 UTC 2011


On 06/27/2011 12:06 PM, Michal Privoznik wrote:
>> That is, if you have command-based custom generators, then each command
>> has to repeat parsing functionality, then call back to common list
>> generators; whereas if you have option-based custom generators, then you
>> have fewer callbacks because all the smarts are tied to well-typed
>> options, and after all, it is the type of each option that determines
>> which list to generate, more than the type of the command that includes
>> the option.
>>
> I was thinking about same feature and started to work on it during this
> weekend. But I ran into a problem. Basically, what I intended to
> implement, is:
> 
> 1.) expand struct vshCmdDef for a char *(*callback) (const char *text,
> int state). But for real benefit, we need connection object, so we could
> e.g. list only inactive networks for 'net-start' command. And this is
> the problem, because we would have to make this object global (since
> readline functions does not allow passing any opaque value).

As gross as it is, a global object isn't entirely bad - virsh is
single-threaded.  And even if we want to make virsh threaded at some
point, I still think we can get away with adding a thread-local access
scheme.

> 
> 2.) expand each command definition with its own completer. So e.g. for
> start commands we could only list inactive domains, networks, pools,
> whatever. For destroy only active objects. And so on.

So maybe we want both - an option-based completer that generates the
initial list, and a command-based completer that can then prune out
irrelevant options?

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110627/1c9f7660/attachment-0001.sig>


More information about the libvir-list mailing list