On Fri, Aug 04, 2023 at 10:58:54AM +0100, Richard W.M. Jones wrote:
On Wed, Aug 02, 2023 at 08:50:37PM -0500, Eric Blake wrote:
> Although we usually map "base:allocation" which doesn't require the
> use of the 64-bit API for flags, this application IS intended to map
> out other metacontexts that might have 64-bit flags. And when
> extended headers are in use, we might as well ask for the server to
> give us extents as large as it wants, rather than breaking things up
> at 4G boundaries.
>
> At the time this patch was written, there are no known servers that
> actually provide a metacontext with 64-bit flags. However, that is
> planned for the nbdkit v3 protocol.
>
> Signed-off-by: Eric Blake <eblake(a)redhat.com>
> Reviewed-by: Richard W.M. Jones <rjones(a)redhat.com>
> ---
>
> v4: no change
> ---
> info/map.c | 65 ++++++++++++++++++++++++++++--------------------------
> 1 file changed, 34 insertions(+), 31 deletions(-)
>
> diff --git a/info/map.c b/info/map.c
> index 1169fce4..50b058f2 100644
> --- a/info/map.c
> +++ b/info/map.c
> @@ -36,13 +36,13 @@
>
> #include "nbdinfo.h"
>
> -DEFINE_VECTOR_TYPE (uint32_vector, uint32_t);
> +DEFINE_VECTOR_TYPE (uint64_vector, uint64_t);
>
> @@ -120,7 +122,8 @@ extent_callback (void *user_data, const char
*metacontext,
> * print_extents below.
> */
> for (i = 0; i < nr_entries; ++i) {
> - if (uint32_vector_append (list, entries[i]) == -1) {
> + if (uint64_vector_append (list, entries[i].length) == -1 ||
> + uint64_vector_append (list, entries[i].flags) == -1) {
I guess there's a case for making it save the nbd_extent here rather
than pretend that we're still collecting a flat array of pairs, but it
simplifies the changes later. Maybe that's something we can do in
future.
Yeah, I went for the minimal change. Defining a vector type of
nbd_extent would probably be nicer; but as it is more invasive, I'll
do it as a followup patch to see how it compares in lines of code.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:
qemu.org |
libguestfs.org