On Thu, Dec 31, 2009 at 08:18:40AM -0600, Anthony Liguori wrote:
> On 12/31/2009 12:38 AM, Avi Kivity wrote:
> >On 12/31/2009 12:46 AM, Anthony Liguori wrote:
> >>>I wasn't worried about that, only the increased code duplication.
> >>
> >>
> >>I wasn't thinking there would be an info ioapic command but rather a
> >>generic device-info command that would work with any qdev device. No
> >>code duplication (in fact, much, much less in the long term).
> >
> >Machine printing isn't going to work. The information needs to be
> >formatted to be legible and bit fields decoded. Some field's
> >interpretation may depend on the value of others.
>
> The cases where you want to have complex display of a device's state
> is the exception and it should be treated as such.
>
This is the other way around. We always want to have complex display of
a device's state, but because we have many devices and not many
resources it is impossible to achieve.
> The common case is where you just want to see the state of the
> device. We support hundreds of devices. We can have one code path
> that displays 95% of them with a couple devices that have exceptions
> or we could have hundreds of these commands that aren't consistent
> because they're all open-coded.
I am not against having common code path that prints out state of all
devices. It just different from what I am trying to achieve with my patch.
My patch adds parsing and pretty-printing of device state and that's the
part that is not addressed with your common code scenario.
>
> In some case machine
> >printing of vmstate will show you the history of that devices live
> >migration bug fixes in addition to its state.
>
> I don't see this as a bad thing.
>
> Regards,
>
> Anthony Liguori
--
Gleb.
