Anthony Liguori <[email protected]> writes:
> Kevin Wolf <[email protected]> writes:
>
>> Am 25.09.2012 14:57, schrieb Anthony Liguori:
>>> Paolo Bonzini <[email protected]> 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.
