| Message ID | 20201030062434.3629438-1-armbru@redhat.com |
|---|---|
| State | Accepted |
| Commit | 143d51e1792ecf2c8e5b0fc3a8c6022676c723d4 |
| Headers | show |
| Series | [v2] block: Remove unused BlockDeviceMapEntry | expand |
On 30.10.20 07:24, Markus Armbruster wrote: > BlockDeviceMapEntry has never been used. It was added in commit > facd6e2 "so that it is published through the introspection mechanism." > What exactly introspecting types that aren't used for anything could > accomplish isn't clear. What "introspection mechanism" to use is also > nebulous. To the best of my knowledge, there has never been one that > covered this type. Certainly not query-qmp-schema, which includes > only types that are actually used in QMP. > > Not being able to introspect BlockDeviceMapEntry hasn't bothered > anyone enough to complain in almost four years. Get rid of it. > > Cc: Paolo Bonzini <pbonzini@redhat.com> > Cc: Eric Blake <eblake@redhat.com> > Reviewed-by: Eric Blake <eblake@redhat.com> > Signed-off-by: Markus Armbruster <armbru@redhat.com> > --- > I found an old patch I neglected to merge. > > Max replied to a remark in Eric's review of v1: > > Max Reitz <mreitz@redhat.com> writes: > > > On 2017-07-28 20:10, Eric Blake wrote: > >> This type is the schema for 'qemu-img map --output=json'. And I had a > >> patch once (that I need to revive) that added a JSON Output visitor; at > >> which point I fixed qemu-img to convert from QAPI to JSON instead of > >> open-coding its construction of its output string, at which point the > >> QAPI generated code for this type is useful. > > (Very late reply, I know, I just stumbled over *MapEntry when looking > > over block-core.json what we might want to deprecate in 3.0) > > > > We already use MapEntry there -- why don't we output just that instead? > > The only difference seems to be an additional @filename parameter which > > would probably be actually nice to include in the output. > > > > Except that BlockDeviceMapEntry's documentation is better, so we should > > merge that into MapEntry before removing the former. > > > > Max > > https://lists.nongnu.org/archive/html/qemu-devel/2017-12/msg02933.html > > Me doing the doc update Max suggested could take more than one > iteration, as I know nothing about this stuff. Max, could you give it > a try? Feel free to take over my patch. Thanks, done :) https://lists.nongnu.org/archive/html/qemu-block/2020-11/msg00143.html Max
diff --git a/qapi/block-core.json b/qapi/block-core.json index e00fc27b5e..2aa499a72e 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -418,35 +418,6 @@ ## { 'enum': 'BlockDeviceIoStatus', 'data': [ 'ok', 'failed', 'nospace' ] } -## -# @BlockDeviceMapEntry: -# -# Entry in the metadata map of the device (returned by "qemu-img map") -# -# @start: Offset in the image of the first byte described by this entry -# (in bytes) -# -# @length: Length of the range described by this entry (in bytes) -# -# @depth: Number of layers (0 = top image, 1 = top image's backing file, etc.) -# before reaching one for which the range is allocated. The value is -# in the range 0 to the depth of the image chain - 1. -# -# @zero: the sectors in this range read as zeros -# -# @data: reading the image will actually read data from a file (in particular, -# if @offset is present this means that the sectors are not simply -# preallocated, but contain actual data in raw format) -# -# @offset: if present, the image file stores the data for this range in -# raw format at the given offset. -# -# Since: 1.7 -## -{ 'struct': 'BlockDeviceMapEntry', - 'data': { 'start': 'int', 'length': 'int', 'depth': 'int', 'zero': 'bool', - 'data': 'bool', '*offset': 'int' } } - ## # @DirtyBitmapStatus: #