From: Anthony Liguori <anthony@codemonkey.ws>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
quintela@redhat.com, "Richard W.M. Jones" <rjones@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"kvm\@vger.kernel.org" <kvm@vger.kernel.org>,
Bharata B Rao <bharata@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] KVM call agenda for September 25th
Date: Tue, 25 Sep 2012 14:42:25 -0500 [thread overview]
Message-ID: <87zk4dyjmm.fsf@codemonkey.ws> (raw)
In-Reply-To: <5061C4E3.4080005@redhat.com>
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
>
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
quintela@redhat.com, qemu-devel <qemu-devel@nongnu.org>,
"Richard W.M. Jones" <rjones@redhat.com>,
Bharata B Rao <bharata@linux.vnet.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] KVM call agenda for September 25th
Date: Tue, 25 Sep 2012 14:42:25 -0500 [thread overview]
Message-ID: <87zk4dyjmm.fsf@codemonkey.ws> (raw)
In-Reply-To: <5061C4E3.4080005@redhat.com>
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
>
> 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
next prev parent reply other threads:[~2012-09-25 19:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-24 11:28 KVM call agenda for September 25th Juan Quintela
2012-09-24 11:28 ` [Qemu-devel] " Juan Quintela
2012-09-24 11:48 ` Paolo Bonzini
2012-09-24 11:48 ` [Qemu-devel] " Paolo Bonzini
2012-09-25 12:13 ` Richard W.M. Jones
2012-09-25 12:13 ` [Qemu-devel] " Richard W.M. Jones
2012-09-25 12:57 ` Anthony Liguori
2012-09-25 12:57 ` [Qemu-devel] " Anthony Liguori
2012-09-25 13:05 ` Richard W.M. Jones
2012-09-25 13:05 ` [Qemu-devel] " Richard W.M. Jones
2012-09-25 13:14 ` Luiz Capitulino
2012-09-25 13:14 ` Luiz Capitulino
2012-09-25 13:30 ` Paolo Bonzini
2012-09-25 13:30 ` [Qemu-devel] " Paolo Bonzini
2012-09-25 14:51 ` Kevin Wolf
2012-09-25 14:51 ` Kevin Wolf
2012-09-25 15:33 ` Bharata B Rao
2012-09-25 15:33 ` Bharata B Rao
2012-09-25 15:37 ` Paolo Bonzini
2012-09-25 15:37 ` Paolo Bonzini
2012-09-25 19:42 ` Anthony Liguori [this message]
2012-09-25 19:42 ` Anthony Liguori
2012-09-26 7:10 ` Markus Armbruster
2012-09-26 7:10 ` Markus Armbruster
2012-09-25 13:27 ` Luiz Capitulino
2012-09-25 13:27 ` Luiz Capitulino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zk4dyjmm.fsf@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=bharata@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.