qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 4/7] block/block-copy: refactor interfaces to use bytes in


From: Max Reitz
Subject: Re: [PATCH v2 4/7] block/block-copy: refactor interfaces to use bytes instead of end
Date: Fri, 7 Feb 2020 19:01:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 27.11.19 19:08, Vladimir Sementsov-Ogievskiy wrote:
> We have a lot of "chunk_end - start" invocations, let's switch to
> bytes/cur_bytes scheme instead.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
> ---
>  include/block/block-copy.h |  4 +--
>  block/block-copy.c         | 68 ++++++++++++++++++++------------------
>  2 files changed, 37 insertions(+), 35 deletions(-)

[...]

> diff --git a/block/block-copy.c b/block/block-copy.c
> index 94e7e855ef..cc273b6cb8 100644
> --- a/block/block-copy.c
> +++ b/block/block-copy.c

[...]

> @@ -150,24 +150,26 @@ void block_copy_set_callbacks(

[...]

>  static int coroutine_fn block_copy_do_copy(BlockCopyState *s,
> -                                           int64_t start, int64_t end,
> +                                           int64_t start, int64_t bytes,

I wonder whether it would make more sense to make some of these @bytes
parameters plain ints, because...

>                                             bool zeroes, bool *error_is_read)
>  {
>      int ret;
> -    int nbytes = MIN(end, s->len) - start;
> +    int nbytes = MIN(start + bytes, s->len) - start;

...things like this look a bit dangerous now.  So if the interface
already clearly shows that we’re always expecting something less than
INT_MAX, it might all be a bit clearer.

I’ll leave it up to you:

Reviewed-by: Max Reitz <address@hidden>

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]