Anthony Liguori wrote: > On 05/22/2010 01:55 PM, Avi Kivity wrote: >> On 05/22/2010 11:18 AM, Jan Kiszka wrote: >>> From: Jan Kiszka<jan.kis...@siemens.com> >>> >>> This introduces device_show, a monitor command that saves the vmstate of >>> a qdev device and visualizes it. QMP is also supported. Buffers are cut >>> after 16 byte by default, but the full content can be requested via >>> '-f'. To pretty-print sub-arrays, vmstate is extended to store the start >>> index name. A new qerror is introduced to signal a missing vmstate. And >>> it comes with documentation. >>> >>> + >>> +Dump a snapshot of the device state. Buffers are cut after 16 bytes >>> unless >>> +a full dump is requested. >>> + >>> +Arguments: >>> + >>> +- "path": the device's qtree path or unique ID (json-string) >> >> This may be ambiguous. >> >>> +- "full": report full state (json-bool, optional) >> >> Is this needed for QMP? The client can always truncate it to any length. >> >>> + >>> +Schema of returned object: >>> + >>> +{ "device": json-string, "id": json-string, "fields" : [ >>> field-objects ] } >>> + >>> +The field object array may be empty, otherwise it consists of >>> + >>> +{ "name": json-string, "size": json-int, "elems": [ element-objects ] } >>> + >>> +"size" describes the real number of bytes required for a binary >>> representation >>> +of a single field element in the array. The actually transfered >>> amount may be >>> +smaller unless a full dump was requested. >> >> This converts the entire qdev tree into an undocumented stable >> protocol (the qdev paths were already in this state I believe). This >> really worries me. > > N.B. the association with qdev is only in identifying the device. The > contents of the device's state are not part of qdev but rather part of > vmstate. vmstate is something that we already guarantee to be stable > since that's required for live migration compatibility.
In contrast to save/loadvm, device_show does not provide a backward-compatible output. Not only field names can change (as a result of internal refactoring), fields may even disappear, new ones may pop up. vmstate makes this transparent for reading of old states, but not for visualization. That said, I see no use case yet that would justify the effort for making state dumps as stable as vmstates. Jan
signature.asc
Description: OpenPGP digital signature