Luiz Capitulino wrote:
On Thu, 10 Dec 2009 18:24:38 +0200
Avi Kivity <a...@redhat.com> wrote:

Let me put it another way, I don't think adding null to the json parser and incorporating it into this command is a good idea at this stage in the release so if we want to do something like this, we need to defer it to 0.13.

I agree there are some instances where null could be useful. I think we can get away without it here though.
For 'name', definitely, since it's known to exist. It would be nice to have consistency in how features are presented, though.

 Following what you propose, if it's known to exist then we should
never return an empty dict.

 There are other commands that might require adjustments, for example
'info kvm' has a 'present' key. If QEMU is built w/o KVM support, then
this key will be 'false'. Should we return an empty dict then?

 HPET is another example, currently it's only compiled in if the
target is i386. Otherwise the command won't even be available, and
we have more commands with conditional features/compilation.

 So, what I arguably did wrong here was starting the conversion
work before defining all these rules.

The monitor in general is very ad-hoc. The fact that the info commands don't behave consistently shouldn't be a surprise.

Let's focus on converting the remaining monitor commands. The goal is that any user of the monitor today can convert over to QMP.

Once we've achieved that goal, let's start looking at introducing proper commands that make sense and are consistent.

--
Regards,

Anthony Liguori



Reply via email to