[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 0/1] QOM type names and QAPI
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH RFC 0/1] QOM type names and QAPI |
Date: |
Fri, 29 Jan 2021 12:17:52 +0000 |
User-agent: |
Mutt/1.14.6 (2020-07-11) |
On Fri, Jan 29, 2021 at 12:01:53PM +0000, Peter Maydell wrote:
> On Fri, 29 Jan 2021 at 08:15, Markus Armbruster <armbru@redhat.com> wrote:
> > 2. We have some 550 type names containing '.'. QAPI's naming rules
> > could be relaxed to accept '.', but keyval_parse()'s can't.
> >
> > Aside: I wish keyval_parse() would use '/' instead of '.', but it's
> > designed to be compatible to the block layer's existing use of
> > dotted keys (shoehorned into QemuOpts).
>
> > Of the type names containing '.' or '+'[**], 293 are CPUs, 107 are
> > machines, and 150 are something else. 48 of them can be plugged with
> > -device, all s390x or spapr CPUs.
> >
> > Can we get rid of '.'?
>
> 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.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|