Re: [Qemu-devel] KVM call agenda for September 25th

[Markus Armbruster <armbru@redhat.com>]

Anthony Liguori <anthony@codemonkey.ws> writes:

> Kevin Wolf <kwolf@redhat.com> writes:
>
>> Am 25.09.2012 14:57, schrieb Anthony Liguori:
>>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>> 
>>>> Il 24/09/2012 13:28, Juan Quintela ha scritto:
>>>>> Hi
>>>>>
>>>>> Please send in any agenda items you are interested in covering.
>>>>
>>>> URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
>>>> same code.
>>> 
>>> The call is a bit late for Bharata but I think copying is the way to go.
>>> 
>>> Something I've been thinking about since this discussion started
>>> though.  Maybe we could standardize on using URIs as short-hand syntax
>>> for backends.
>>
>> Compared with QemuOpts, it's not really short-hand or even convenient
>> for manual use. For management tools it might be nice because URIs have
>> a well-known syntax, can escape anything and implementations exist. But
>> I think we must still maintain an easy to use syntax for human users.
>>
>>> For example:
>>> 
>>> qemu -hda file:///foo.img
>>> 
>>> Or:
>>> 
>>> qemu -device virtio-net-pci,netdev=tap:///vnet0?script=/etc/qemu-ifup
>>> 
>>> Or:
>>> 
>>> qemu -device \
>>>       isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=off
>>
>> Your examples kind of prove this: They aren't much shorter than what
>> exists today, but they contain ? and &, which are nasty characters on
>> the command line.
>>
>>> This works particularly well with a "treat unknown options as -device"
>>> mechanism so that we could do:
>>> 
>>> qemu -isa-serial chr=tcp://localhost:1025/?server=on&wait=off
>>> 
>>> We could even introduce a secondary implied option to shorten this
>>> further to:
>>> 
>>> qemu -isa-serial tcp://localhost:1025/?server=on&wait=off

Too much magic for my taste.

I'm afraid it leads to rather obscure error messages on misspellings.

>> This is something that I was thinking of in the context of -blockdev a
>> while ago (without URLs): Define the block device inside of -device
>> specifications. The problem of nesting an option string inside another
>> one is solved in theory by URLs because they allow (nested) escaping,
>> but in practice we'll need to use some kind of brackets instead if we
>> want it to be usable.
>
> qemu -isa-serial 'tcp://localhost:1025/?server=on&wait=off'
>
> I don't think it's really that better.  And yeah, your thoughts are
> exactly mine.  Having two syntaxes allows us to use a single option.
>
> Hopefully most options could avoid having query parameters so escaping
> wasn't a problem.  It's unfortunate that the TCP character device uses
> client mode by default.

You could fold a limited set of common flags into the scheme.  Prior
art: socat supports syntax like

    TCP:<host>:<port>
    TCP4:<host>:<port>
    TCP-LISTEN:<port>

I'm not saying it's a good idea for QEMU.