Am 25.09.2012 14:57, schrieb Anthony Liguori: > Paolo Bonzini <pbonzini@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
