Re: [RFC-PATCH 1/5] unaligned: introduce common header

[Harvey Harrison]

On Mon, 2008-11-10 at 11:49 +0000, Will Newton wrote:
> On Mon, Nov 10, 2008 at 4:22 AM, Harvey Harrison
> <harvey.harrison@xxxxxxxxx> wrote:
> 
> (add back lkml cc that I mistakenly dropped)
> 
> > On Sat, 2008-11-08 at 12:47 +0000, Will Newton wrote:
> >> On Wed, Nov 5, 2008 at 6:16 PM, Harvey Harrison
> >> <harvey.harrison@xxxxxxxxx> wrote:
> >>
> >> > The memmove-based arches (m32r, xtensa, h8300) are likely going to be fine with this change
> >> > barring compiler bugs that made them go with memmove in the first place.
> >>
> >> As I understand it the need for the memmove implementation is not
> >> compiler bugs but default struct alignment. The packed struct
> >> implementation will only work with compilers where structs can be
> >> aligned on byte boundaries, it's fairly common for RISC architectures
> >> to align structs to 4 or 8 byte boundaries.
> >
> > Which I believe is disabled entirely using __attribute__((packed)), no?
> 
> As far as I am aware the packed attribute is handled in this way for
> some toolchains (arm in particular). Not everybody does it, and for
> good reasons. For example if I have this struct on an architecture
> with 8 byte default struct alignment:
> 

I should have been more careful with my wording here, I meant that no
alignment assumptions are made when accessing a packed struct through
a pointer, as is the case with the kernel version.

> struct foo {
>     u64 big_data;
>     u8 small_data;
>     u32 medium_data;
> } __attribute__((packed));
> 
> Should big_data be accessed as 8 byte load instructions rather than
> one 64bit load instruction? It's a pretty large performance penalty to
> pay when all I really want is for medium_data to be accessed
> correctly.

In this particular case, packed isn't right as you know big_data is
aligned (as long as you can guarantee the struct alignment), so you'd
probably want:

struct foo {
	u64 big_data;
	u8 small_data;
	u32 medium_data __attribute__((__packed__));
}

But that's not what we're talking about in the kernel's case.

Harvey

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