[libvirt] [PATCH 00/34] network events feature v2

[Michele Paolino]

Sorry, I noticed just now that here you are discussing about the problem 
with the compilation of libvirt on ARM platforms. An alternative 
solution can be ATTRIBUTE_PACKED.

I've sent right now to the ML a patch based on this.

Michele

On 12/12/2013 17:11, Daniel P. Berrange wrote:
> On Wed, Dec 11, 2013 at 12:28:32PM -0700, Eric Blake wrote:
>> On 12/11/2013 12:15 PM, Eric Blake wrote:
>>
>>> struct _virObjectEvent {
>>>      virObject parent;
>>>      int eventID;
>>>      virObjectMeta meta;
>>> };
>>>
>>> Only has alignment specified by virObject (which in turn is unsigned
>>> int, int, void*),
>> struct _virObject {
>>      unsigned int magic;
>>      int refs;
>>      virClassPtr klass;
>> };
>>
>>
>>> I think one possible solution would be as simple as altering
>>> src/util/virobject.h to change 'magic' from 'unsigned int' to 'unsigned
>>> long long' - then ALL virObject structs will be forcefully aligned to
>>> the worst case between void* and long long, so that any subclass can use
>>> long long without requiring stricter alignment than the parent class,
>>> and so that downcasting code like domain_event.c no longer warns.  But
>>> it does make every object consume more memory on 64-bit platforms (from
>>> 16 bytes into 24 bytes), is that okay?
>> Or maybe even change _virObject to contain a union:
>>
>> struct _virObject {
>>      union {
>>          long long align;
>>          struct {
>>              unsigned int magic;
>>              int refs;
>>          } s;
>>      } u;
>>      virClassPtr klass;
>> }
>>
>> which keeps the size at 16 bytes on 64-bit platform, keeps things at 12
>> bytes on 32-bit platforms that don't care about long long alignment, and
>> for ARM (*) would change things from 12 to 16 bytes with 8-byte
>> alignment for the long long.
>>
>> Yeah, that means using obj->u.s.refs instead of obj->refs, but most code
>> shouldn't be directly mucking with object-internal fields, so hopefully
>> the fallout would be limited to just virobject.c (if only C99 had
>> anonymous struct/unions; C11 does, but we don't require that yet).
>>
>> (*) Am I correct that your platform with the compile failure is a 32-bit
>> ARM platform with 4-byte pointers? Because if it were 64-bit, then I
>> would have guessed that an 8-byte pointer would already be forcing
>> 8-byte alignment, such that use of 'long long' in a subclass wouldn't be
>> warning about changed alignment.
> That seems reasonable to me - it makes sense that we should have
> our base object type be nicely aligned, instead of trying to fix
> this in the events code (and potentially anywhere else using
> objects in the future).
>
> Daniel


-- 
*Michele Paolino*, Virtualization R&D Engineer
Virtual Open Systems
/Open Source  KVM Virtualization  Developments/
/Multicore Systems Virtualization Porting Services/
Web/:/www.virtualopensystems. <http://www.virtualopensystems.com/>com 
<http://www.virtualopensystems.com/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131212/6375bbe2/attachment-0001.htm>