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

Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller bitmap into a larger one



On Thu, 2014-11-20 at 16:27 -0500, Boris Ostrovsky wrote:

> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..2a08bef 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap 
> *dptr,
>      memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
>  }
>  
> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
> +                               const libxl_bitmap *sptr)
> +{
> +    assert(dptr->size >= sptr->size);
> +    memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
> +}
> +
Looking at other callers of libxl_bitmap_copy(), I think something like
this makes sense for pretty much all of them.

And even abstracting from them, and thinking to how a function like
'libxl_bitmap_copy()' this should behave, copying only the "common part"
makes sense to me.

So, should we make libxl_bitmap_copy() behave like implemented above,
rather than introducing a new function. I know this is public stable
API, but I think this is a fine behavioral change, isn't it?

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.