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

[Kevin Wolf <kwolf@redhat.com>]

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

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.

Kevin