[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 11/21/2014 06:26 AM, Dario Faggioli wrote:
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?

I did consider this but wasn't sure about it from the point of view of API behavior. If people feel it's OK to slightly change behavior here I'd rather go this route.


-boris

_______________________________________________
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®.