[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1282317570.15124.20.camel@dhcp231-77.rdu.redhat.com>
Date: Fri, 20 Aug 2010 11:19:30 -0400
From: Eric Paris <eparis@...hat.com>
To: Andreas Schwab <schwab@...hat.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@...hos.com>,
Andreas Gruenbacher <agruen@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: struct fanotify_event_metadata
On Fri, 2010-08-20 at 15:27 +0200, Andreas Schwab wrote:
> Eric Paris <eparis@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists