Eduardo Habkost <ehabk...@redhat.com> writes: > On Fri, Jan 29, 2021 at 02:25:56PM +0100, Paolo Bonzini wrote: >> On 29/01/21 13:17, Daniel P. Berrangé wrote: >> > > On this one, my vote would be "no". "Versioned machine names >> > > include the QEMU version number" is pretty well entrenched, >> > > and requiring users to remember that when they want version 4.2 >> > > they need to remember some other way of writing it than "4.2" >> > > seems rather unfriendly. And 550 uses of '.' is a lot. >> > We can't make keyval_parse() accept "/" instead of ".", but can >> > we make it accept "/" in addition to ".", and then encourage "/" ? >> > >> > People simply wouldnt be able to use "." as keyval separator if >> > they're using typenames containing "." (or would have to escape >> > the typename. >> >> '.' is much more common than '/', and is shared by about all programming >> languages that have JSON-ish data structures natively. So using '/' seems >> decidedly worse to me. > > Worse than what, exactly? > > Accepting "/" when "." is ambiguous seems decidedly better than > the following alternatives: > - renaming machine types to names like "q35-5-0"; or > - having to escape "." in the command line.
Yes. However, the ambiguity arises only when type names occur as key, as I noted in my followup Message-ID: <875z3g2c1f....@dusky.pond.sub.org>. I figure we could relax the QAPI enum naming rules to permit '.', with drawbacks that feel tolerable. One of them: if we ever manage to put QAPI enums in a key position, we're screwed :)