On 02/08/2018 04:37 AM, Cornelia Huck wrote:

@@ -373,7 +373,7 @@ static void s390_machine_reset(void)
/* all cpus are stopped - configure and start the ipl cpu only */
      s390_ipl_prepare_cpu(ipl_cpu);
-    s390_cpu_set_state(CPU_STATE_OPERATING, ipl_cpu);
+    s390_cpu_set_state(CPU_INFOS390_STATE_OPERATING, ipl_cpu);


Exposing the state as a QAPI enum has the unfortunate side effect of
that new name. It feels slightly awkward to me, as it is a state for
real decisions and not just for info statements...

I asked Viktor to use the qapi enum instead of having two sets of defines that
we need to keep in sync. (in fact 3, as the kernel kvm mpstate definition is 
also
there).

Agreed, using the QAPI enum makes sense.


But yes, the INFO in that name is somewhat strange. No good idea though.

Can we call the enum CpuS390State instead of CpuInfoS390State (while
keeping the CpuInfoS390 name)? Or does that violate any QAPI rules?

The name of the enum is not important to introspection; and what's more, you can set the 'prefix':'...' key in QAPI to pick an enum naming in the C code that is saner than what the generator would automatically produce from the enum name itself (see qapi/crypto.json for some examples).

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Reply via email to