* Re: [Qemu-devel] KVM call agenda for September 25th
2012-09-25 12:57 ` Anthony Liguori
@ 2012-09-25 13:05 ` Richard W.M. Jones
2012-09-25 13:14 ` Luiz Capitulino
` (2 subsequent siblings)
3 siblings, 0 replies; 13+ messages in thread
From: Richard W.M. Jones @ 2012-09-25 13:05 UTC (permalink / raw)
To: Anthony Liguori
Cc: Paolo Bonzini, Bharata B Rao, qemu-devel, kvm@vger.kernel.org,
quintela
On Tue, Sep 25, 2012 at 07:57:53AM -0500, Anthony Liguori wrote:
> 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.
>
> For example:
>
> qemu -hda file:///foo.img
>
> Or:
>
> qemu -device virtio-net-pci,netdev=tap:///vnet0?script=/etc/qemu-ifup
This is roughly what the original URI code from libvirt is used for:
http://libvirt.org/remote.html#Remote_URI_reference
It works well because URIs are standardized, well understood, support
escaping, and are widely supported by client libraries/languages.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Qemu-devel] KVM call agenda for September 25th
2012-09-25 12:57 ` Anthony Liguori
2012-09-25 13:05 ` Richard W.M. Jones
@ 2012-09-25 13:14 ` Luiz Capitulino
2012-09-25 13:30 ` Paolo Bonzini
2012-09-25 14:51 ` Kevin Wolf
3 siblings, 0 replies; 13+ messages in thread
From: Luiz Capitulino @ 2012-09-25 13:14 UTC (permalink / raw)
To: Anthony Liguori
Cc: kvm@vger.kernel.org, quintela, qemu-devel, Richard W.M. Jones,
Bharata B Rao, Paolo Bonzini
On Tue, 25 Sep 2012 07:57:53 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:
> 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.
Agreed, just suggested this for qmp commands taking a file path and
a fd name in other thread.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] KVM call agenda for September 25th
2012-09-25 12:57 ` Anthony Liguori
2012-09-25 13:05 ` Richard W.M. Jones
2012-09-25 13:14 ` Luiz Capitulino
@ 2012-09-25 13:30 ` Paolo Bonzini
2012-09-25 14:51 ` Kevin Wolf
3 siblings, 0 replies; 13+ messages in thread
From: Paolo Bonzini @ 2012-09-25 13:30 UTC (permalink / raw)
To: Anthony Liguori
Cc: Richard W.M. Jones, Bharata B Rao, qemu-devel,
kvm@vger.kernel.org, quintela
Il 25/09/2012 14:57, Anthony Liguori ha scritto:
> 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.
>
> 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
>
> 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
Interesting idea...
Paolo
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] KVM call agenda for September 25th
2012-09-25 12:57 ` Anthony Liguori
` (2 preceding siblings ...)
2012-09-25 13:30 ` Paolo Bonzini
@ 2012-09-25 14:51 ` Kevin Wolf
2012-09-25 15:33 ` Bharata B Rao
2012-09-25 19:42 ` Anthony Liguori
3 siblings, 2 replies; 13+ messages in thread
From: Kevin Wolf @ 2012-09-25 14:51 UTC (permalink / raw)
To: Anthony Liguori
Cc: kvm@vger.kernel.org, quintela, qemu-devel, Richard W.M. Jones,
Bharata B Rao, Paolo Bonzini
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [Qemu-devel] KVM call agenda for September 25th
2012-09-25 14:51 ` Kevin Wolf
@ 2012-09-25 15:33 ` Bharata B Rao
2012-09-25 15:37 ` Paolo Bonzini
2012-09-25 19:42 ` Anthony Liguori
1 sibling, 1 reply; 13+ messages in thread
From: Bharata B Rao @ 2012-09-25 15:33 UTC (permalink / raw)
To: Kevin Wolf
Cc: kvm@vger.kernel.org, quintela, qemu-devel, Richard W.M. Jones,
Anthony Liguori, Paolo Bonzini
On Tue, Sep 25, 2012 at 04:51:15PM +0200, Kevin Wolf wrote:
> Am 25.09.2012 14:57, schrieb Anthony Liguori:
> > 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.
Right. '&' can't even be specified directly on command line since that will
result in qemu command being treated as a background job with anything after
'&' being discarded. I realized that '&' needs to be escaped as %26.
Regards,
Bharata.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] KVM call agenda for September 25th
2012-09-25 15:33 ` Bharata B Rao
@ 2012-09-25 15:37 ` Paolo Bonzini
0 siblings, 0 replies; 13+ messages in thread
From: Paolo Bonzini @ 2012-09-25 15:37 UTC (permalink / raw)
To: bharata
Cc: Kevin Wolf, kvm@vger.kernel.org, quintela, qemu-devel,
Richard W.M. Jones, Anthony Liguori
Il 25/09/2012 17:33, Bharata B Rao ha scritto:
>>> 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.
> Right. '&' can't even be specified directly on command line since that will
> result in qemu command being treated as a background job with anything after
> '&' being discarded. I realized that '&' needs to be escaped as %26.
No, %26 is escaped at the URL level, i.e. it doesn't start a new
argumnt. If you need to pass '&' in the shell, simply use quoting or
write it \&.
Paolo
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] KVM call agenda for September 25th
2012-09-25 14:51 ` Kevin Wolf
2012-09-25 15:33 ` Bharata B Rao
@ 2012-09-25 19:42 ` Anthony Liguori
2012-09-26 7:10 ` Markus Armbruster
1 sibling, 1 reply; 13+ messages in thread
From: Anthony Liguori @ 2012-09-25 19:42 UTC (permalink / raw)
To: Kevin Wolf
Cc: kvm@vger.kernel.org, quintela, qemu-devel, Richard W.M. Jones,
Bharata B Rao, Paolo Bonzini
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] KVM call agenda for September 25th
2012-09-25 19:42 ` Anthony Liguori
@ 2012-09-26 7:10 ` Markus Armbruster
0 siblings, 0 replies; 13+ messages in thread
From: Markus Armbruster @ 2012-09-26 7:10 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, kvm@vger.kernel.org, quintela, qemu-devel,
Richard W.M. Jones, Bharata B Rao, Paolo Bonzini
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.
^ permalink raw reply [flat|nested] 13+ messages in thread