Re: [PATCH 00/34] network events feature v2

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

 



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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]