On Fri, 2010-08-20 at 15:27 +0200, Andreas Schwab wrote:
quoted text
> Eric Paris <eparis@redhat.com> writes:
> 
> > Can you help me understand the packed attribute and why it hurts in this
> > case?
> 
> It changes the alignment of all applicable objects to 1 which means that
> the compiler cannot assume _any_ aligment.  Thus on STRICT_ALIGNMENT
> targets it has to use more expensive access methods to avoid generating
> unaligned loads and stores (unless it can infer proper alignment from
> the context).

Andreas suggested (I accidentally dropped the list when I ask him) I use
natural alignment and explicit padding rather than ((packed))

I'm open to the idea but I want to make it idiot proof (aka I won't
screw it up later)  My best offhand idea would be to do something like
so:

Expose this to userspace:
struct fanotify_event_metadata {
        __u32 event_len;
        __u32 vers;
        __s32 fd;
        __u64 mask;
        __s64 pid;
};

Wrap this in #ifdef KERNEL
struct fanotify_event_metadata_packed {
        __u32 event_len;
        __u32 vers;
        __s32 fd;
        __u64 mask;
        __s64 pid;
} __attribute__ ((packed));

Then add:
BUILD_BUG_ON(sizeof(struct fanotify_event_metadata) != 
             sizeof(struct fanotify_event_metadata_packed);

Is that a good way to make the actual object non-packed but keep myself
from ever letting it fail alignment and padding requirements?

-Eric

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/