include/hw/arm/armv7m.h | 2 +- include/hw/arm/fsl-imx25.h | 2 +- include/hw/arm/fsl-imx31.h | 2 +- include/hw/arm/fsl-imx6.h | 2 +- include/hw/arm/fsl-imx6ul.h | 2 +- include/hw/arm/fsl-imx7.h | 2 +- include/hw/arm/xlnx-zynqmp.h | 2 +- include/hw/cris/etraxfs.h | 2 +- include/hw/i386/ich9.h | 2 +- include/hw/misc/grlib_ahb_apb_pnp.h | 4 ++-- include/hw/misc/zynq-xadc.h | 2 +- include/hw/register.h | 2 +- include/hw/sparc/grlib.h | 6 +++--- hw/arm/xilinx_zynq.c | 2 +- hw/audio/cs4231.c | 2 +- hw/block/fdc.c | 4 ++-- hw/char/etraxfs_ser.c | 2 +- hw/cris/axis_dev88.c | 6 +++--- hw/display/tcx.c | 2 +- hw/intc/etraxfs_pic.c | 2 +- hw/microblaze/xlnx-zynqmp-pmu.c | 2 +- hw/misc/zynq_slcr.c | 2 +- hw/sparc/sun4m.c | 12 ++++++------ hw/timer/etraxfs_timer.c | 2 +- softmmu/vl.c | 2 +- tests/vmstate-static-checker-data/dump1.json | 4 ++-- tests/vmstate-static-checker-data/dump2.json | 4 ++-- 27 files changed, 40 insertions(+), 40 deletions(-)
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
will become a problem when we
* Switch from QemuOpts to keyval_parse()
QOM type names must not contain special characters, unless we
introduce more quoting. Which we shouldn't, because the value of
special characters in names is negligible compared to the hassle of
having to quote them.
* QAPIfy (the compile-time static parts of) QOM
QOM type names become QAPI enum values. They must conform to QAPI
naming rules.
Adopting QAPI naming rules for QOM type names takes care of both.
Let's review the existing offenders.
1. We have a few type names containing ',', and one containing ' '.
The former require QemuOpts / keyval quoting (double the comma),
the latter requires shell quoting. There is no excuse for making
our users remember and do such crap. PATCH 1 eliminates it.
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).
3. We have six type names containing '+'. Four of them also contain
'.'. Naming rules could be relaxed to accept '+'. I'm not sure
it's worthwhile.
4. We have 19 names starting with a digit. Three of them also contain
'.'. Leading digit is okay as QAPI enum, not okay as
keyval_parse() key fragment. We can either rename these types, or
make keyval_parse() a bit less strict.
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 '.'?
I figure we could keep old names as deprecated aliases if we care.
Perhaps just the ones that can be plugged with -device.
[*] Paolo's "[PATCH 04/25] keyval: accept escaped commas in implied
option" provides for comma-quoting. I'm ignoring it here for brevity.
I assure you it doesn't weaken my argument.
[**] They are:
603e_v1.1-powerpc-cpu
603e_v1.1-powerpc64-cpu
603e_v1.2-powerpc-cpu
603e_v1.2-powerpc64-cpu
603e_v1.3-powerpc-cpu
603e_v1.3-powerpc64-cpu
603e_v1.4-powerpc-cpu
603e_v1.4-powerpc64-cpu
603e_v2.2-powerpc-cpu
603e_v2.2-powerpc64-cpu
603e_v4.1-powerpc-cpu
603e_v4.1-powerpc64-cpu
604e_v1.0-powerpc-cpu
604e_v1.0-powerpc64-cpu
604e_v2.2-powerpc-cpu
604e_v2.2-powerpc64-cpu
604e_v2.4-powerpc-cpu
604e_v2.4-powerpc64-cpu
7400_v1.0-powerpc-cpu
7400_v1.0-powerpc64-cpu
7400_v1.1-powerpc-cpu
7400_v1.1-powerpc64-cpu
7400_v2.0-powerpc-cpu
7400_v2.0-powerpc64-cpu
7400_v2.1-powerpc-cpu
7400_v2.1-powerpc64-cpu
7400_v2.2-powerpc-cpu
7400_v2.2-powerpc64-cpu
7400_v2.6-powerpc-cpu
7400_v2.6-powerpc64-cpu
7400_v2.7-powerpc-cpu
7400_v2.7-powerpc64-cpu
7400_v2.8-powerpc-cpu
7400_v2.8-powerpc64-cpu
7400_v2.9-powerpc-cpu
7400_v2.9-powerpc64-cpu
740_v1.0-powerpc-cpu
740_v1.0-powerpc64-cpu
740_v2.0-powerpc-cpu
740_v2.0-powerpc64-cpu
740_v2.1-powerpc-cpu
740_v2.1-powerpc64-cpu
740_v2.2-powerpc-cpu
740_v2.2-powerpc64-cpu
740_v3.0-powerpc-cpu
740_v3.0-powerpc64-cpu
740_v3.1-powerpc-cpu
740_v3.1-powerpc64-cpu
7410_v1.0-powerpc-cpu
7410_v1.0-powerpc64-cpu
7410_v1.1-powerpc-cpu
7410_v1.1-powerpc64-cpu
7410_v1.2-powerpc-cpu
7410_v1.2-powerpc64-cpu
7410_v1.3-powerpc-cpu
7410_v1.3-powerpc64-cpu
7410_v1.4-powerpc-cpu
7410_v1.4-powerpc64-cpu
7441_v2.1-powerpc-cpu
7441_v2.1-powerpc64-cpu
7441_v2.10-powerpc-cpu
7441_v2.10-powerpc64-cpu
7441_v2.3-powerpc-cpu
7441_v2.3-powerpc64-cpu
7445_v1.0-powerpc-cpu
7445_v1.0-powerpc64-cpu
7445_v2.1-powerpc-cpu
7445_v2.1-powerpc64-cpu
7445_v3.2-powerpc-cpu
7445_v3.2-powerpc64-cpu
7445_v3.3-powerpc-cpu
7445_v3.3-powerpc64-cpu
7445_v3.4-powerpc-cpu
7445_v3.4-powerpc64-cpu
7447_v1.0-powerpc-cpu
7447_v1.0-powerpc64-cpu
7447_v1.1-powerpc-cpu
7447_v1.1-powerpc64-cpu
7447a_v1.0-powerpc-cpu
7447a_v1.0-powerpc64-cpu
7447a_v1.1-powerpc-cpu
7447a_v1.1-powerpc64-cpu
7447a_v1.2-powerpc-cpu
7447a_v1.2-powerpc64-cpu
7448_v1.0-powerpc-cpu
7448_v1.0-powerpc64-cpu
7448_v1.1-powerpc-cpu
7448_v1.1-powerpc64-cpu
7448_v2.0-powerpc-cpu
7448_v2.0-powerpc64-cpu
7448_v2.1-powerpc-cpu
7448_v2.1-powerpc64-cpu
7450_v1.0-powerpc-cpu
7450_v1.0-powerpc64-cpu
7450_v1.1-powerpc-cpu
7450_v1.1-powerpc64-cpu
7450_v1.2-powerpc-cpu
7450_v1.2-powerpc64-cpu
7450_v2.0-powerpc-cpu
7450_v2.0-powerpc64-cpu
7450_v2.1-powerpc-cpu
7450_v2.1-powerpc64-cpu
7451_v2.10-powerpc-cpu
7451_v2.10-powerpc64-cpu
7451_v2.3-powerpc-cpu
7451_v2.3-powerpc64-cpu
7455_v1.0-powerpc-cpu
7455_v1.0-powerpc64-cpu
7455_v2.1-powerpc-cpu
7455_v2.1-powerpc64-cpu
7455_v3.2-powerpc-cpu
7455_v3.2-powerpc64-cpu
7455_v3.3-powerpc-cpu
7455_v3.3-powerpc64-cpu
7455_v3.4-powerpc-cpu
7455_v3.4-powerpc64-cpu
7457_v1.0-powerpc-cpu
7457_v1.0-powerpc64-cpu
7457_v1.1-powerpc-cpu
7457_v1.1-powerpc64-cpu
7457_v1.2-powerpc-cpu
7457_v1.2-powerpc64-cpu
7457a_v1.0-powerpc-cpu
7457a_v1.0-powerpc64-cpu
7457a_v1.1-powerpc-cpu
7457a_v1.1-powerpc64-cpu
7457a_v1.2-powerpc-cpu
7457a_v1.2-powerpc64-cpu
745_v1.0-powerpc-cpu
745_v1.0-powerpc64-cpu
745_v1.1-powerpc-cpu
745_v1.1-powerpc64-cpu
745_v2.0-powerpc-cpu
745_v2.0-powerpc64-cpu
745_v2.1-powerpc-cpu
745_v2.1-powerpc64-cpu
745_v2.2-powerpc-cpu
745_v2.2-powerpc64-cpu
745_v2.3-powerpc-cpu
745_v2.3-powerpc64-cpu
745_v2.4-powerpc-cpu
745_v2.4-powerpc64-cpu
745_v2.5-powerpc-cpu
745_v2.5-powerpc64-cpu
745_v2.6-powerpc-cpu
745_v2.6-powerpc64-cpu
745_v2.7-powerpc-cpu
745_v2.7-powerpc64-cpu
745_v2.8-powerpc-cpu
745_v2.8-powerpc64-cpu
750_v1.0-powerpc-cpu
750_v1.0-powerpc64-cpu
750_v2.0-powerpc-cpu
750_v2.0-powerpc64-cpu
750_v2.1-powerpc-cpu
750_v2.1-powerpc64-cpu
750_v2.2-powerpc-cpu
750_v2.2-powerpc64-cpu
750_v3.0-powerpc-cpu
750_v3.0-powerpc64-cpu
750_v3.1-powerpc-cpu
750_v3.1-powerpc64-cpu
750cl_v1.0-powerpc-cpu
750cl_v1.0-powerpc64-cpu
750cl_v2.0-powerpc-cpu
750cl_v2.0-powerpc64-cpu
750cx_v1.0-powerpc-cpu
750cx_v1.0-powerpc64-cpu
750cx_v2.0-powerpc-cpu
750cx_v2.0-powerpc64-cpu
750cx_v2.1-powerpc-cpu
750cx_v2.1-powerpc64-cpu
750cx_v2.2-powerpc-cpu
750cx_v2.2-powerpc64-cpu
750cxe_v2.1-powerpc-cpu
750cxe_v2.1-powerpc64-cpu
750cxe_v2.2-powerpc-cpu
750cxe_v2.2-powerpc64-cpu
750cxe_v2.3-powerpc-cpu
750cxe_v2.3-powerpc64-cpu
750cxe_v2.4-powerpc-cpu
750cxe_v2.4-powerpc64-cpu
750cxe_v2.4b-powerpc-cpu
750cxe_v2.4b-powerpc64-cpu
750cxe_v3.0-powerpc-cpu
750cxe_v3.0-powerpc64-cpu
750cxe_v3.1-powerpc-cpu
750cxe_v3.1-powerpc64-cpu
750cxe_v3.1b-powerpc-cpu
750cxe_v3.1b-powerpc64-cpu
750fx_v1.0-powerpc-cpu
750fx_v1.0-powerpc64-cpu
750fx_v2.0-powerpc-cpu
750fx_v2.0-powerpc64-cpu
750fx_v2.1-powerpc-cpu
750fx_v2.1-powerpc64-cpu
750fx_v2.2-powerpc-cpu
750fx_v2.2-powerpc64-cpu
750fx_v2.3-powerpc-cpu
750fx_v2.3-powerpc64-cpu
750gx_v1.0-powerpc-cpu
750gx_v1.0-powerpc64-cpu
750gx_v1.1-powerpc-cpu
750gx_v1.1-powerpc64-cpu
750gx_v1.2-powerpc-cpu
750gx_v1.2-powerpc64-cpu
750l_v2.0-powerpc-cpu
750l_v2.0-powerpc64-cpu
750l_v2.1-powerpc-cpu
750l_v2.1-powerpc64-cpu
750l_v2.2-powerpc-cpu
750l_v2.2-powerpc64-cpu
750l_v3.0-powerpc-cpu
750l_v3.0-powerpc64-cpu
750l_v3.2-powerpc-cpu
750l_v3.2-powerpc64-cpu
755_v1.0-powerpc-cpu
755_v1.0-powerpc64-cpu
755_v1.1-powerpc-cpu
755_v1.1-powerpc64-cpu
755_v2.0-powerpc-cpu
755_v2.0-powerpc64-cpu
755_v2.1-powerpc-cpu
755_v2.1-powerpc64-cpu
755_v2.2-powerpc-cpu
755_v2.2-powerpc64-cpu
755_v2.3-powerpc-cpu
755_v2.3-powerpc64-cpu
755_v2.4-powerpc-cpu
755_v2.4-powerpc64-cpu
755_v2.5-powerpc-cpu
755_v2.5-powerpc64-cpu
755_v2.6-powerpc-cpu
755_v2.6-powerpc64-cpu
755_v2.7-powerpc-cpu
755_v2.7-powerpc64-cpu
755_v2.8-powerpc-cpu
755_v2.8-powerpc64-cpu
970_v2.2-powerpc64-cpu
970_v2.2-spapr-cpu-core
970fx_v1.0-powerpc64-cpu
970fx_v2.0-powerpc64-cpu
970fx_v2.1-powerpc64-cpu
970fx_v3.0-powerpc64-cpu
970fx_v3.1-powerpc64-cpu
970mp_v1.0-powerpc64-cpu
970mp_v1.0-spapr-cpu-core
970mp_v1.1-powerpc64-cpu
970mp_v1.1-spapr-cpu-core
ALTR.timer
Sun-UltraSparc-IIIi+-sparc64-cpu
Sun-UltraSparc-IV+-sparc64-cpu
arm.cortex-a9-global-timer
aspeed.fmc-ast2400
aspeed.fmc-ast2500
aspeed.fmc-ast2600
aspeed.gpio
aspeed.gpio-ast2400
aspeed.gpio-ast2500
aspeed.gpio-ast2600
aspeed.gpio-ast2600-1_8v
aspeed.i2c
aspeed.i2c-ast2400
aspeed.i2c-ast2500
aspeed.i2c-ast2600
aspeed.rtc
aspeed.scu
aspeed.scu-ast2400
aspeed.scu-ast2500
aspeed.scu-ast2600
aspeed.sdhci
aspeed.sdmc
aspeed.sdmc-ast2400
aspeed.sdmc-ast2500
aspeed.sdmc-ast2600
aspeed.smc
aspeed.smc-ast2400
aspeed.spi1-ast2400
aspeed.spi1-ast2500
aspeed.spi1-ast2600
aspeed.spi2-ast2500
aspeed.spi2-ast2600
aspeed.timer
aspeed.timer-ast2400
aspeed.timer-ast2500
aspeed.timer-ast2600
aspeed.vic
aspeed.wdt
aspeed.wdt-ast2400
aspeed.wdt-ast2500
aspeed.wdt-ast2600
aspeed.xdma
cadence.sdhci
cfi.pflash01
cfi.pflash02
exynos4210.clk
exynos4210.combiner
exynos4210.fimd
exynos4210.gic
exynos4210.i2c
exynos4210.irq_gate
exynos4210.mct
exynos4210.pmu
exynos4210.pwm
exynos4210.rng
exynos4210.rtc
exynos4210.uart
imx.avic
imx.ccm
imx.enet
imx.epit
imx.fec
imx.gpio
imx.i2c
imx.rngc
imx.serial
imx.spi
imx.usbphy
imx2.wdt
imx25.ccm
imx25.gpt
imx31.ccm
imx31.gpt
imx6.ccm
imx6.gpt
imx6.src
imx6ul.ccm
imx7.analog
imx7.ccm
imx7.gpr
imx7.gpt
imx7.snvs
loongson.liointc
mchp.pfsoc.ddr_cfg
mchp.pfsoc.ddr_sgmii_phy
mchp.pfsoc.ioscb
mchp.pfsoc.sysreg
microbit.i2c
microchip.pfsoc
nrf51_soc.gpio
nrf51_soc.nvm
nrf51_soc.rng
nrf51_soc.timer
nrf51_soc.uart
pc-1.0-machine
pc-1.1-machine
pc-1.2-machine
pc-1.3-machine
pc-i440fx-1.4-machine
pc-i440fx-1.5-machine
pc-i440fx-1.6-machine
pc-i440fx-1.7-machine
pc-i440fx-2.0-machine
pc-i440fx-2.1-machine
pc-i440fx-2.10-machine
pc-i440fx-2.11-machine
pc-i440fx-2.12-machine
pc-i440fx-2.2-machine
pc-i440fx-2.3-machine
pc-i440fx-2.4-machine
pc-i440fx-2.5-machine
pc-i440fx-2.6-machine
pc-i440fx-2.7-machine
pc-i440fx-2.8-machine
pc-i440fx-2.9-machine
pc-i440fx-3.0-machine
pc-i440fx-3.1-machine
pc-i440fx-4.0-machine
pc-i440fx-4.1-machine
pc-i440fx-4.2-machine
pc-i440fx-5.0-machine
pc-i440fx-5.1-machine
pc-i440fx-5.2-machine
pc-i440fx-6.0-machine
pc-q35-2.10-machine
pc-q35-2.11-machine
pc-q35-2.12-machine
pc-q35-2.4-machine
pc-q35-2.5-machine
pc-q35-2.6-machine
pc-q35-2.7-machine
pc-q35-2.8-machine
pc-q35-2.9-machine
pc-q35-3.0-machine
pc-q35-3.1-machine
pc-q35-4.0-machine
pc-q35-4.0.1-machine
pc-q35-4.1-machine
pc-q35-4.2-machine
pc-q35-5.0-machine
pc-q35-5.1-machine
pc-q35-5.2-machine
pc-q35-6.0-machine
power10_v1.0-pnv-chip
power10_v1.0-powernv-cpu-core
power10_v1.0-powerpc64-cpu
power10_v1.0-spapr-cpu-core
power5+_v2.1-powerpc64-cpu
power5+_v2.1-spapr-cpu-core
power7+_v2.1-powerpc64-cpu
power7+_v2.1-spapr-cpu-core
power7_v2.3-powerpc64-cpu
power7_v2.3-spapr-cpu-core
power8_v2.0-pnv-chip
power8_v2.0-powernv-cpu-core
power8_v2.0-powerpc64-cpu
power8_v2.0-spapr-cpu-core
power8e_v2.1-pnv-chip
power8e_v2.1-powernv-cpu-core
power8e_v2.1-powerpc64-cpu
power8e_v2.1-spapr-cpu-core
power8nvl_v1.0-pnv-chip
power8nvl_v1.0-powernv-cpu-core
power8nvl_v1.0-powerpc64-cpu
power8nvl_v1.0-spapr-cpu-core
power9_v1.0-powerpc64-cpu
power9_v1.0-spapr-cpu-core
power9_v2.0-pnv-chip
power9_v2.0-powernv-cpu-core
power9_v2.0-powerpc64-cpu
power9_v2.0-spapr-cpu-core
pseries-2.1-machine
pseries-2.10-machine
pseries-2.11-machine
pseries-2.12-machine
pseries-2.12-sxxm-machine
pseries-2.2-machine
pseries-2.3-machine
pseries-2.4-machine
pseries-2.5-machine
pseries-2.6-machine
pseries-2.7-machine
pseries-2.8-machine
pseries-2.9-machine
pseries-3.0-machine
pseries-3.1-machine
pseries-4.0-machine
pseries-4.1-machine
pseries-4.2-machine
pseries-5.0-machine
pseries-5.1-machine
pseries-5.2-machine
pseries-6.0-machine
qemu:dummy
qemu:iommu-memory-region
qemu:memory-region
riscv.hart_array
riscv.lowrisc.ibex.soc
riscv.sifive.clint
riscv.sifive.e.prci
riscv.sifive.e.soc
riscv.sifive.plic
riscv.sifive.test
riscv.sifive.u.otp
riscv.sifive.u.prci
riscv.sifive.u.soc
s390-ccw-virtio-2.10-machine
s390-ccw-virtio-2.11-machine
s390-ccw-virtio-2.12-machine
s390-ccw-virtio-2.4-machine
s390-ccw-virtio-2.5-machine
s390-ccw-virtio-2.6-machine
s390-ccw-virtio-2.7-machine
s390-ccw-virtio-2.8-machine
s390-ccw-virtio-2.9-machine
s390-ccw-virtio-3.0-machine
s390-ccw-virtio-3.1-machine
s390-ccw-virtio-4.0-machine
s390-ccw-virtio-4.1-machine
s390-ccw-virtio-4.2-machine
s390-ccw-virtio-5.0-machine
s390-ccw-virtio-5.1-machine
s390-ccw-virtio-5.2-machine
s390-ccw-virtio-6.0-machine
sifive.pdma
sifive_soc.gpio
virt-2.10-machine
virt-2.11-machine
virt-2.12-machine
virt-2.6-machine
virt-2.7-machine
virt-2.8-machine
virt-2.9-machine
virt-3.0-machine
virt-3.1-machine
virt-4.0-machine
virt-4.1-machine
virt-4.2-machine
virt-5.0-machine
virt-5.1-machine
virt-5.2-machine
virt-6.0-machine
xenfv-3.1-machine
xenfv-4.2-machine
xlnx-zynmp.rtc
xlnx.axi-dma
xlnx.axi-ethernet
xlnx.dpdma
xlnx.pmu_io_intc
xlnx.ps7-dev-cfg
xlnx.ps7-qspi
xlnx.ps7-spi
xlnx.usmp-gqspi
xlnx.v-dp
xlnx.versal-usb2
xlnx.versal-usb2-ctrl-regs
xlnx.xps-ethernetlite
xlnx.xps-intc
xlnx.xps-spi
xlnx.xps-timer
xlnx.xps-uartlite
xlnx.zdma
xlnx.zynqmp-can
xlnx.zynqmp_ipi
z10BC.2-base-s390x-cpu
z10BC.2-s390x-cpu
z10EC.2-base-s390x-cpu
z10EC.2-s390x-cpu
z10EC.3-base-s390x-cpu
z10EC.3-s390x-cpu
z13.2-base-s390x-cpu
z13.2-s390x-cpu
z14.2-base-s390x-cpu
z14.2-s390x-cpu
z196.2-base-s390x-cpu
z196.2-s390x-cpu
z890.2-base-s390x-cpu
z890.2-s390x-cpu
z890.3-base-s390x-cpu
z890.3-s390x-cpu
z900.2-base-s390x-cpu
z900.2-s390x-cpu
z900.3-base-s390x-cpu
z900.3-s390x-cpu
z990.2-base-s390x-cpu
z990.2-s390x-cpu
z990.3-base-s390x-cpu
z990.3-s390x-cpu
z990.4-base-s390x-cpu
z990.4-s390x-cpu
z990.5-base-s390x-cpu
z990.5-s390x-cpu
z9BC.2-base-s390x-cpu
z9BC.2-s390x-cpu
z9EC.2-base-s390x-cpu
z9EC.2-s390x-cpu
z9EC.3-base-s390x-cpu
z9EC.3-s390x-cpu
zEC12.2-base-s390x-cpu
zEC12.2-s390x-cpu
Markus Armbruster (1):
hw: Replace anti-social QOM type names
include/hw/arm/armv7m.h | 2 +-
include/hw/arm/fsl-imx25.h | 2 +-
include/hw/arm/fsl-imx31.h | 2 +-
include/hw/arm/fsl-imx6.h | 2 +-
include/hw/arm/fsl-imx6ul.h | 2 +-
include/hw/arm/fsl-imx7.h | 2 +-
include/hw/arm/xlnx-zynqmp.h | 2 +-
include/hw/cris/etraxfs.h | 2 +-
include/hw/i386/ich9.h | 2 +-
include/hw/misc/grlib_ahb_apb_pnp.h | 4 ++--
include/hw/misc/zynq-xadc.h | 2 +-
include/hw/register.h | 2 +-
include/hw/sparc/grlib.h | 6 +++---
hw/arm/xilinx_zynq.c | 2 +-
hw/audio/cs4231.c | 2 +-
hw/block/fdc.c | 4 ++--
hw/char/etraxfs_ser.c | 2 +-
hw/cris/axis_dev88.c | 6 +++---
hw/display/tcx.c | 2 +-
hw/intc/etraxfs_pic.c | 2 +-
hw/microblaze/xlnx-zynqmp-pmu.c | 2 +-
hw/misc/zynq_slcr.c | 2 +-
hw/sparc/sun4m.c | 12 ++++++------
hw/timer/etraxfs_timer.c | 2 +-
softmmu/vl.c | 2 +-
tests/vmstate-static-checker-data/dump1.json | 4 ++--
tests/vmstate-static-checker-data/dump2.json | 4 ++--
27 files changed, 40 insertions(+), 40 deletions(-)
--
2.26.2
Forgot to mention: Based-on: <20210125162402.1807394-1-armbru@redhat.com> [PATCH 0/3] Drop deprecated floppy config & bogus -drive if=T
Markus Armbruster <armbru@redhat.com> writes: > 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 > will become a problem when we > > * Switch from QemuOpts to keyval_parse() > > QOM type names must not contain special characters, unless we > introduce more quoting. Which we shouldn't, because the value of > special characters in names is negligible compared to the hassle of > having to quote them. > > * QAPIfy (the compile-time static parts of) QOM > > QOM type names become QAPI enum values. They must conform to QAPI > naming rules. > > Adopting QAPI naming rules for QOM type names takes care of both. > > Let's review the existing offenders. > > 1. We have a few type names containing ',', and one containing ' '. > The former require QemuOpts / keyval quoting (double the comma), > the latter requires shell quoting. There is no excuse for making > our users remember and do such crap. PATCH 1 eliminates it. > > 2. We have some 550 type names containing '.'. QAPI's naming rules > could be relaxed to accept '.', but keyval_parse()'s can't. Thinko: keyval_parse() copes. QOM type names occur as *value*, not as key. One more thing on 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. > 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). > > 3. We have six type names containing '+'. Four of them also contain > '.'. Naming rules could be relaxed to accept '+'. I'm not sure > it's worthwhile. > > 4. We have 19 names starting with a digit. Three of them also contain > '.'. Leading digit is okay as QAPI enum, not okay as > keyval_parse() key fragment. We can either rename these types, or > make keyval_parse() a bit less strict. > > 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 '.'? > > I figure we could keep old names as deprecated aliases if we care. > Perhaps just the ones that can be plugged with -device. > > > [*] Paolo's "[PATCH 04/25] keyval: accept escaped commas in implied > option" provides for comma-quoting. I'm ignoring it here for brevity. > I assure you it doesn't weaken my argument. > > [**] They are: > 603e_v1.1-powerpc-cpu [...]
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. thanks -- PMM
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 :|
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. Paolo
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. -- Eduardo
Eduardo Habkost <ehabkost@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.fsf@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 :)
© 2016 - 2024 Red Hat, Inc.