Re: [PATCH v7 4/9] qcow2_format.py: Dump bitmap directory information

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

12.06.2020 03:04, Andrey Shinkevich wrote:
> Read and dump entries from the bitmap directory of QCOW2 image.
> It extends the output in the test case #291.
> 
> Header extension:
> magic                     0x23852875 (Bitmaps)
> ...
> Bitmap name               bitmap-1
> flag                      auto
> table size                8 (bytes)
> bitmap_table_offset       0x90000
> bitmap_table_size         1
> flags                     0
> type                      1
> granularity_bits          16
> name_size                 8
> extra_data_size           0
> 
> Suggested-by: Kevin Wolf <kwolf@redhat.com>
> Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

Hmm I don't remember me gave it..

> ---
>   tests/qemu-iotests/291.out         | 52 ++++++++++++++++++++++++++
>   tests/qemu-iotests/qcow2_format.py | 75 ++++++++++++++++++++++++++++++++++++++
>   2 files changed, 127 insertions(+)
> 
> diff --git a/tests/qemu-iotests/291.out b/tests/qemu-iotests/291.out
> index ccfcdc5..d847419 100644
> --- a/tests/qemu-iotests/291.out
> +++ b/tests/qemu-iotests/291.out
> @@ -33,6 +33,27 @@ reserved32                0
>   bitmap_directory_size     0x40
>   bitmap_directory_offset   0x510000
>   
> +Bitmap name               b1
> +table size                8 (bytes)
> +bitmap_table_offset       0x4e0000
> +bitmap_table_size         1
> +flags                     0
> +type                      1
> +granularity_bits          19
> +name_size                 2
> +extra_data_size           0
> +
> +Bitmap name               b2
> +flag                      auto
> +table size                8 (bytes)
> +bitmap_table_offset       0x500000
> +bitmap_table_size         1
> +flags                     2

both having flags and flag in the output looks strange.

If you want good human look of flags field, you should implement a special formatter-class for it, like Flags64.
Maybe, something like this:

flags      0x3 (in_use auto)


> +type                      1
> +granularity_bits          16
> +name_size                 2
> +extra_data_size           0
> +
>   
>   === Bitmap preservation not possible to non-qcow2 ===
>   
> @@ -98,6 +119,37 @@ reserved32                0
>   bitmap_directory_size     0x60
>   bitmap_directory_offset   0x520000
>   
> +Bitmap name               b1
> +table size                8 (bytes)
> +bitmap_table_offset       0x470000
> +bitmap_table_size         1
> +flags                     0
> +type                      1
> +granularity_bits          19
> +name_size                 2
> +extra_data_size           0
> +
> +Bitmap name               b2
> +flag                      auto
> +table size                8 (bytes)
> +bitmap_table_offset       0x490000
> +bitmap_table_size         1
> +flags                     2
> +type                      1
> +granularity_bits          16
> +name_size                 2
> +extra_data_size           0
> +
> +Bitmap name               b0
> +table size                8 (bytes)
> +bitmap_table_offset       0x510000
> +bitmap_table_size         1
> +flags                     0
> +type                      1
> +granularity_bits          16
> +name_size                 2
> +extra_data_size           0
> +
>   
>   === Check bitmap contents ===
>   
> diff --git a/tests/qemu-iotests/qcow2_format.py b/tests/qemu-iotests/qcow2_format.py
> index d4f0000..90eff92 100644
> --- a/tests/qemu-iotests/qcow2_format.py
> +++ b/tests/qemu-iotests/qcow2_format.py
> @@ -103,6 +103,10 @@ class Qcow2Struct(metaclass=Qcow2StructMeta):
>               print('{:<25} {}'.format(f[2], value_str))
>   
>   
> +# seek relative to the current position in the file
> +FROM_CURRENT = 1

Firstly, I though that it's a global variable to control class behavior. Only than I understood that you just decided to use a named constant instead of just 1...

So, I'd prefer to use just 1.

> +
> +
>   class Qcow2BitmapExt(Qcow2Struct):
>   
>       fields = (
> @@ -112,6 +116,73 @@ class Qcow2BitmapExt(Qcow2Struct):
>           ('u64', '{:#x}', 'bitmap_directory_offset')
>       )
>   
> +    def read_bitmap_directory(self, fd):
> +        self.bitmaps = []
> +        fd.seek(self.bitmap_directory_offset)
> +        buf_size = struct.calcsize(Qcow2BitmapDirEntry.fmt)
> +
> +        for n in range(self.nb_bitmaps):
> +            buf = fd.read(buf_size)
> +            dir_entry = Qcow2BitmapDirEntry(data=buf)

Base class of Qcow2BitmapDirEntry can load from fd. We should definitely utilize this possibility, instead of writing it again.

> +            fd.seek(dir_entry.extra_data_size, FROM_CURRENT)
> +            bitmap_name = fd.read(dir_entry.name_size)
> +            dir_entry.name = bitmap_name.decode('ascii')

You should initialize object in its constructor, not by hand here.

Actually, the code here should look like this:

self.bitmap_directory = [Qcow2BitmapDirEntry(fd) for _ in range(self.nb_bitmaps)]

OK, you may leave a loop, and even calculating of final alignment here, but real fields should be read and initialized in Qcow2BitmapDirEntry constructor
    

> +            self.bitmaps.append(dir_entry)
> +            entry_raw_size = dir_entry.bitmap_dir_entry_raw_size()
> +            shift = ((entry_raw_size + 7) & ~7) - entry_raw_size
> +            fd.seek(shift, FROM_CURRENT)
> +
> +    def load(self, fd):
> +        self.read_bitmap_directory(fd)

Let's load in __init__, why to force user call additional .load after object creation?

> +
> +    def dump(self):
> +        super().dump()
> +        for bm in self.bitmaps:
> +            bm.dump_bitmap_dir_entry()
> +
> +
> +BME_FLAG_IN_USE = 1 << 0
> +BME_FLAG_AUTO = 1 << 1
> +
> +
> +class Qcow2BitmapDirEntry(Qcow2Struct):
> +
> +    name = ''
> +
> +    fields = (
> +        ('u64', '{:#x}', 'bitmap_table_offset'),
> +        ('u32', '{}',    'bitmap_table_size'),

please, don't do internal indenting, I've dropped it from all other classes here.

> +        ('u32', '{}',    'flags'),
> +        ('u8',  '{}',    'type'),
> +        ('u8',  '{}',    'granularity_bits'),
> +        ('u16', '{}',    'name_size'),
> +        ('u32', '{}',    'extra_data_size')
> +    )
> +
> +    def __init__(self, data):
> +        super().__init__(data=data)
> +
> +        self.bitmap_table_bytes = self.bitmap_table_size \
> +            * struct.calcsize('Q')

struct.calcsize('Q') isn't more friendly than just 64.

Also, you tend to prepare everything you want to dump in a constructor. Why?
I'd prefer not to have attributes bitmap_table_bytes and bitmap_table_size
stored together, it's obviously too redundant. You can always do
print(self.bitmap_table_size * 64), no reason to store the calculated value.

> +
> +        self.bitmap_flags = []
> +        if (self.flags & BME_FLAG_IN_USE):
> +            self.bitmap_flags.append("in-use")
> +        if (self.flags & BME_FLAG_AUTO):
> +            self.bitmap_flags.append("auto")

Again, for this we need a separate formatter class, like Flags64

> +
> +    def bitmap_dir_entry_raw_size(self):
> +        return struct.calcsize(self.fmt) + self.name_size + \
> +            self.extra_data_size
> +
> +    def dump_bitmap_dir_entry(self):

this method should be called just dump

> +        print()

this is extra formatting print-line. Do it on upper level, it's unrelated to Qcow2BitmapDirEntry class itself

> +        print(f'{"Bitmap name":<25} {self.name}')
> +        for fl in self.bitmap_flags:
> +            print(f'{"flag":<25} {fl}')
> +        print(f'{"table size":<25} {self.bitmap_table_bytes} {"(bytes)"}')

Why do we need this additional representation of bitmap table size?

> +        super().dump()
> +
>   
>   QCOW2_EXT_MAGIC_BITMAPS = 0x23852875
>   
> @@ -253,6 +324,10 @@ class QcowHeader(Qcow2Struct):
>               else:
>                   self.extensions.append(ext)
>   
> +        for ext in self.extensions:
> +            if ext.obj is not None:
> +                ext.obj.load(fd)
> +

I don't like this chunk, it breaks encapsulation. Why QcowHeader object should know that some of extensions may have internal obj, and to initialize it we need to call its .load method explicitly?
If extension wants to load some additional data it should do it in a constructor.

>       def update_extensions(self, fd):
>   
>           fd.seek(self.header_length)
> 


-- 
Best regards,
Vladimir