On Wed, Apr 9, 2014 at 7:56 PM, Markus Armbruster <arm...@redhat.com> wrote: > We have a number of device model names containing '.'. They're unusable > with -global. That's because "-global A.B.C=foo" gets parsed as > > driver = "A" > property = "B.C" > value = "foo". > > Wrong when the device model name is really A.B and the property is C, > e.g. "-global cfi.pflash01.name". > > Related problem: QemuOpts ID may contain '.'. Such IDs are in fact > common practice. Unfortunately, they're unusable with -set. For > instance, -set A.B.C.D=foo gets parsed as > > group = "A" > id = "B" > arg = "C.D" > value = "foo" > > Wrong when the id is really B.C and the arg is D, e.g. "-device > isa-serial,id=s.0 -set device.s.0.chardev=c0". This issue isn't limited > to devices. > > Related historical problem: commit b560a9a. > > Possible solutions: > > * Outlaw '.' in QemuOpts parameter names (and thus device model names > and property names, because QemuOpts is a major way for users to > specify them). >
I like the "."s because they mean "this is where the vendor stops and the IP name starts". Whereas "-" just delimits multiple words. We seem to be running our of characters however with these overloading problems. But AFAICT ":" is largely unused (within this context anyway). So how about: "-" seperates multiple words in a name ":" splits logical groupings of multiple words as appropriate ( e.g. some-vendor:their-device ) "," demilits multiple command line arguments "." accesses property within an object "/" walks the canonical path I do also need to confess to my alternate agenda of device tree driven QEMU - I am still parsing device trees and directly mapping the compatible strings to QOM type names for machine creation. Ambiguity of "-" as meaning the "," or the "-" is hard to deal with. Regards, Peter > * Resolve the syntactic ambiguity semantically (ugh) > > * Extend the syntax of -global and -set to let users avoid the issue, or > replace them outright > > * Use the old ostrich algorithm > > Andreas, what restrictions does QOM place on QOM path component names? > No '/', obviously. Anything else? >