docs/system/arm/xlnx-versal-virt.rst | 4 ++-- include/hw/misc/xlnx-versal-cframe-reg.h | 2 +- include/hw/misc/xlnx-versal-cfu.h | 6 +++--- include/hw/misc/xlnx-versal-crl.h | 2 +- include/hw/nvram/xlnx-efuse.h | 2 +- include/hw/nvram/xlnx-versal-efuse.h | 4 ++-- include/hw/nvram/xlnx-zynqmp-efuse.h | 2 +- 7 files changed, 11 insertions(+), 11 deletions(-)
We got rid of QOM type names containing ',' in 6.0, but some have crept back in. Replace them just like we did in 6.0. Cover letter of 6.0's replacement: https://lore.kernel.org/qemu-devel/20210304140229.575481-1-armbru@redhat.com/ Markus Armbruster (2): docs/system/arm: Fix for rename of type "xlnx.bbram-ctrl" hw: Replace anti-social QOM type names (again) docs/system/arm/xlnx-versal-virt.rst | 4 ++-- include/hw/misc/xlnx-versal-cframe-reg.h | 2 +- include/hw/misc/xlnx-versal-cfu.h | 6 +++--- include/hw/misc/xlnx-versal-crl.h | 2 +- include/hw/nvram/xlnx-efuse.h | 2 +- include/hw/nvram/xlnx-versal-efuse.h | 4 ++-- include/hw/nvram/xlnx-zynqmp-efuse.h | 2 +- 7 files changed, 11 insertions(+), 11 deletions(-) -- 2.41.0
On Mon, Nov 13, 2023 at 02:43:42PM +0100, Markus Armbruster wrote: > We got rid of QOM type names containing ',' in 6.0, but some have > crept back in. Replace them just like we did in 6.0. It is practical to add assert(strchr(name, ',') == NULL) to some place in QOM to stop them coming back yet again ? > > Cover letter of 6.0's replacement: > https://lore.kernel.org/qemu-devel/20210304140229.575481-1-armbru@redhat.com/ > > Markus Armbruster (2): > docs/system/arm: Fix for rename of type "xlnx.bbram-ctrl" > hw: Replace anti-social QOM type names (again) > > docs/system/arm/xlnx-versal-virt.rst | 4 ++-- > include/hw/misc/xlnx-versal-cframe-reg.h | 2 +- > include/hw/misc/xlnx-versal-cfu.h | 6 +++--- > include/hw/misc/xlnx-versal-crl.h | 2 +- > include/hw/nvram/xlnx-efuse.h | 2 +- > include/hw/nvram/xlnx-versal-efuse.h | 4 ++-- > include/hw/nvram/xlnx-zynqmp-efuse.h | 2 +- > 7 files changed, 11 insertions(+), 11 deletions(-) > > -- > 2.41.0 > > With 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 :|
Cc: the other QOM maintainers
Daniel P. Berrangé <berrange@redhat.com> writes:
> On Mon, Nov 13, 2023 at 02:43:42PM +0100, Markus Armbruster wrote:
>> We got rid of QOM type names containing ',' in 6.0, but some have
>> crept back in. Replace them just like we did in 6.0.
>
> It is practical to add
>
> assert(strchr(name, ',') == NULL)
>
> to some place in QOM to stop them coming back yet again ?
This adds a naming rule to QOM. Right now, QOM has none whatsoever,
which I've long called out as a mistake.
I'm all for correcting that mistake, but I'd go further than just
outlawing ','.
Discussed in more depth here:
>> Cover letter of 6.0's replacement:
>> https://lore.kernel.org/qemu-devel/20210304140229.575481-1-armbru@redhat.com/
Let me copy the text for convenience.
QAPI has naming rules. docs/devel/qapi-code-gen.txt:
=== Naming rules and reserved names ===
All names must begin with a letter, and contain only ASCII letters,
digits, hyphen, and underscore. There are two exceptions: enum values
may start with a digit, and names that are downstream extensions (see
section Downstream extensions) start with underscore.
[More on reserved names, upper vs. lower case, '-' vs. '_'...]
The generator enforces the rules.
Naming rules help in at least three ways:
1. They help with keeping names in interfaces consistent and
predictable.
2. They make avoiding collisions with the users' names in the
generator simpler.
3. They enable quote-less, evolvable syntax.
For instance, keyval_parse() syntax consists of names, values, and
special characters ',', '=', '.'
Since names cannot contain special characters, there is no need for
quoting[*]. Simple.
Values are unrestricted, but only ',' is special there. We quote
it by doubling.
Together, we get exactly the same quoting as in QemuOpts. This is
a feature.
If we ever decice to extend key syntax, we have plenty of special
characters to choose from. This is also a feature.
Both features rely on naming rules.
QOM has no naming rules whatsoever. Actual names aren't nearly as bad
as they could be. Still, there are plenty of "funny" names. This may
become a problem when we
* Switch from QemuOpts to keyval_parse()
Compared to QemuOpts, keyval_parse() restricts *keys*, but not
*values*.
"Funny" type names occuring as values are no worse than before:
quoting issues, described below.
Type names occuring in keys must be valid QAPI names. Should be
avoidable.
* QAPIfy (the compile-time static parts of) QOM
QOM type names become QAPI enum values. They must conform to QAPI
enum naming rules.
[...]
One more thing on relaxing QAPI naming rules. QAPI names get mapped
to (parts of) C identifiers. These mappings are not injective. The
basic mapping is simple: replace characters other than letters and
digits by '_'.
This means names distinct QAPI names can clash in C. Fairly harmless
when the only "other" characters are '-' and '_'. The more "others" we
permit, the more likely confusing clashes become. Not a show stopper,
"merely" an issue of ergonomics.
On 14/11/2023 08.41, Markus Armbruster wrote: > Cc: the other QOM maintainers > > Daniel P. Berrangé <berrange@redhat.com> writes: > >> On Mon, Nov 13, 2023 at 02:43:42PM +0100, Markus Armbruster wrote: >>> We got rid of QOM type names containing ',' in 6.0, but some have >>> crept back in. Replace them just like we did in 6.0. >> >> It is practical to add >> >> assert(strchr(name, ',') == NULL) >> >> to some place in QOM to stop them coming back yet again ? > > This adds a naming rule to QOM. Right now, QOM has none whatsoever, > which I've long called out as a mistake. > > I'm all for correcting that mistake, but I'd go further than just > outlawing ','. What prevents us from fixing this "mistake"? Is there any compelling reason for keeping the current lax naming rules of QOM? Would there be migration issues if we'd rename the current offenders? (and even if so, couldn't we simply fix that issue by curating an allowlist of old names?) Thomas
Thomas Huth <thuth@redhat.com> writes: > On 14/11/2023 08.41, Markus Armbruster wrote: >> Cc: the other QOM maintainers >> Daniel P. Berrangé <berrange@redhat.com> writes: >> >>> On Mon, Nov 13, 2023 at 02:43:42PM +0100, Markus Armbruster wrote: >>>> We got rid of QOM type names containing ',' in 6.0, but some have >>>> crept back in. Replace them just like we did in 6.0. >>> >>> It is practical to add >>> >>> assert(strchr(name, ',') == NULL) >>> >>> to some place in QOM to stop them coming back yet again ? >> >> This adds a naming rule to QOM. Right now, QOM has none whatsoever, >> which I've long called out as a mistake. >> >> I'm all for correcting that mistake, but I'd go further than just >> outlawing ','. > > What prevents us from fixing this "mistake"? 1. Having to clean up the naming messes we made. This involves backward compatibility arguments and work-arounds. 2. Inertia. > Is there any compelling reason for keeping the current lax naming rules of QOM? Can't think of any but avoiding 1. > Would there be migration issues if we'd rename the current offenders? (and even if so, couldn't we simply fix that issue by curating an allowlist of old names?) I believe migration should not be affected, since migration section names are entirely separate. Mind, I'm no migration expert.
© 2016 - 2024 Red Hat, Inc.