From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] tools/libxl new bitmap functions Date: Fri, 3 Apr 2015 14:34:49 +0000 Message-ID: <1428071687.7917.24.camel@citrix.com> References: <1427996296-27980-1-git-send-email-lindaj@jma3.com> <1428053111.7917.18.camel@citrix.com> <551E9A31.9050105@jma3.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6119844346960779549==" Return-path: In-Reply-To: <551E9A31.9050105@jma3.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "lindaj@jma3.com" Cc: Julien Grall , "lars.kurth@xen.org" , Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============6119844346960779549== Content-Language: en-US Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+Vf+pBsOrGyyFMnWp9zN" --=-+Vf+pBsOrGyyFMnWp9zN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-04-03 at 07:48 -0600, Linda wrote: > Dario, > Hi, One thing: here in the ML, please, don't top post. > I like your comments on naming. We'll see what others say. > As far as difference, at least as I've implemented it, it's the=20 > exclusive or. > Well, then I'd call it libxl_bitmap_xor(). :-) BTW, is there an actual use case for it? Intersection and union, I'm sure they can be useful in many places (I know it from my direct experience!)... xor, not sure I ever needed it. I'm not complaining or objecting, I'm just asking. :-D > To all, > I've been thinking about Konrad's comment that we should disallow= =20 > bitmaps of unequal size, in the XOR/difference function. I've=20 > implemented it, so the resulting bitmap is the size of the larger input= =20 > bitmap, and the bits past the end of the smaller bitmap are all ones. I= =20 > think this is inelegant. > I don't like this either. > Another possibility, is, if two bitmaps are of unequal size, make= =20 > the XOR bitmap be the size of the smaller bitmap. This would actually= =20 > yield a reasonable result. > What do others say? >=20 I'm really not sure. This certainly looks at least better than the solution above, IMO. Another thing that you could do to actually disallow this is to just return an error if you detect the two bitmaps have different sizes, but again, I'm not sure... let's see what Wei and other libxl maintainers (which I'm Cc-ing) think. Regards, Dario > Thanks. >=20 > Linda Jacobson >=20 >=20 > On 4/3/2015 3:25 AM, Dario Faggioli wrote: > > On Thu, 2015-04-02 at 11:38 -0600, Linda Jacobson wrote: > >> From: Linda > >> > >> Added bitmap functions for union intersection and difference betweenn = two bitmaps > >> > > Just wondering, about union and intersection, are them the best names > > for these operations, or do we want libxl_bitmap_or() and > > libxl_bitmap_and()? Personally, I'd go for _and() and _or(), it's more > > common and more consistent with what we have already in the codebase. > > > > About difference, what it the exact intended semantic of that operation= ? > > In set theory, AFAICR, A-B is the set of elements that are in A and are > > not in B. For a binary bitmap, I'd say it is the set of bits that are > > set in A and are not set in B, is it so? Whatever it is, we should writ= e > > it down somewhere, e.g., in libxl_utils.h, as the function's doc > > comment. > > --=-+Vf+pBsOrGyyFMnWp9zN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlUepQcACgkQk4XaBE3IOsRy5QCfctNLvUNduGBCWegiNFmKnqi/ 7wYAnRATzzcnIf45CBms9HO7c3RerePO =7dpx -----END PGP SIGNATURE----- --=-+Vf+pBsOrGyyFMnWp9zN-- --===============6119844346960779549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6119844346960779549==--