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

Re: [Xen-devel] [PATCH v2 24/30] tools/libxc: Modify bitmap operations to take void pointers



On 10/02/16 10:18, Ian Campbell wrote:
> On Wed, 2016-02-10 at 10:07 +0000, Andrew Cooper wrote:
>> On 08/02/16 16:36, Ian Campbell wrote:
>>> On Mon, 2016-02-08 at 16:23 +0000, Tim Deegan wrote:
>>>> At 13:42 +0000 on 05 Feb (1454679737), Andrew Cooper wrote:
>>>>> The type of the pointer to a bitmap is not interesting; it does not
>>>>> affect the
>>>>> representation of the block of bits being pointed to.
>>>> It does affect the alignment, though.  Is this safe on ARM?
>>> Good point. These constructs in the patch:
>>>
>>> +    const unsigned long *addr = _addr;
>>>
>>> Would be broken if _addr were not suitably aligned for an unsigned
>>> long.
>>>
>>> That probably rules out this approach unfortunately.
>> What about reworking libxc bitops in terms of unsigned char?  That
>> should cover all alignment issues.
> Assuming any asm or calls to __builtin_foo backends were adjusted to suite,
> that would be ok, would that be compatible with the Xen side though?

It is all plain C.  What I mean is

-static inline int test_bit(int nr, unsigned long *addr)
+static inline int test_bit(int nr, const void *_addr)
 {
+    const char *addr = _addr;
     return (BITMAP_ENTRY(nr, addr) >> BITMAP_SHIFT(nr)) & 1;
 }

and changing BITMAP_{ENTRY,SHIFT}() to use char rather than unsigned long.

The prototypes still have void *, but char* is used internally which
will match the minimum alignment of any object passed.

~Andrew

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