qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] KVM call agenda for September 25th
Date: Tue, 25 Sep 2012 14:42:25 -0500
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Kevin Wolf <address@hidden> writes:

> Am 25.09.2012 14:57, schrieb Anthony Liguori:
>> Paolo Bonzini <address@hidden> 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.

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.

Regards,

Anthony Liguori


>
> Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]