From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call agenda for September 25th Date: Tue, 25 Sep 2012 14:42:25 -0500 Message-ID: <87zk4dyjmm.fsf@codemonkey.ws> References: <87txunr76j.fsf@trasno.org> <5060488A.1050008@redhat.com> <87obkucl9q.fsf@codemonkey.ws> <5061C4E3.4080005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Paolo Bonzini , quintela@redhat.com, "Richard W.M. Jones" , qemu-devel , "kvm\@vger.kernel.org" , Bharata B Rao To: Kevin Wolf Return-path: Received: from mail-ob0-f174.google.com ([209.85.214.174]:56931 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753889Ab2IYTma (ORCPT ); Tue, 25 Sep 2012 15:42:30 -0400 Received: by obbuo13 with SMTP id uo13so6262163obb.19 for ; Tue, 25 Sep 2012 12:42:29 -0700 (PDT) In-Reply-To: <5061C4E3.4080005@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Kevin Wolf writes: > Am 25.09.2012 14:57, schrieb Anthony Liguori: >> Paolo Bonzini 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGb1c-0004IT-OW for qemu-devel@nongnu.org; Tue, 25 Sep 2012 15:42:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGb1a-0005Ru-Qo for qemu-devel@nongnu.org; Tue, 25 Sep 2012 15:42:32 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:33006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGb1a-0005Rq-Lh for qemu-devel@nongnu.org; Tue, 25 Sep 2012 15:42:30 -0400 Received: by obbta14 with SMTP id ta14so6547732obb.4 for ; Tue, 25 Sep 2012 12:42:29 -0700 (PDT) From: Anthony Liguori In-Reply-To: <5061C4E3.4080005@redhat.com> References: <87txunr76j.fsf@trasno.org> <5060488A.1050008@redhat.com> <87obkucl9q.fsf@codemonkey.ws> <5061C4E3.4080005@redhat.com> Date: Tue, 25 Sep 2012 14:42:25 -0500 Message-ID: <87zk4dyjmm.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] KVM call agenda for September 25th List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: "kvm@vger.kernel.org" , quintela@redhat.com, qemu-devel , "Richard W.M. Jones" , Bharata B Rao , Paolo Bonzini Kevin Wolf writes: > Am 25.09.2012 14:57, schrieb Anthony Liguori: >> Paolo Bonzini 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