Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755914Ab1FTVEZ (ORCPT ); Mon, 20 Jun 2011 17:04:25 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:45879 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1755458Ab1FTVEX (ORCPT ); Mon, 20 Jun 2011 17:04:23 -0400 Date: Mon, 20 Jun 2011 17:04:23 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Nicolas Pitre cc: Alexander Holler , Arnd Bergmann , , , , lkml , Rabin Vincent Subject: Re: [PATCH] USB: ehci: use packed,aligned(4) instead of removing the packed attribute In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2638 Lines: 78 On Mon, 20 Jun 2011, Nicolas Pitre wrote: > On Mon, 20 Jun 2011, Alan Stern wrote: > > > On Mon, 20 Jun 2011, Alexander Holler wrote: > > > > > I see it that way: packed is needed to be sure that at least for struct > > > ehci_regs there are no padding bytes inbetween the members. > > > > But is it _really_ needed? > > > > > It might > > > work without, but that depends on the compiler (-version, architecture, > > > whatever). > > > > Have there _ever_ been _any_ combinations of compiler, version, > > architecture, whatever, that had unwanted padding bytes in this > > structure? > > This can be determined by simple code inspection. > > If you must have struct members which are not aligned to their natural > size then you need __packed. Example: > > struct foo { > u8 a; > u16 b; > u32 c; > u64 d; > }; > > Without __packed, there will be padding between a and b, and between c > and d. One byte of padding between a and b is enough. No more is needed, and the compiler would have to be pretty stupid to add anything else. > If the order of the members in this struct were reversed, then > everything would be naturally aligned and no padding between members > would be inserted. > > The size of structures is normally rounded up with padding to the size > of the largest basic element it contains. Example: > > struct foo { > u64 a; > u8 b; > }; > > Here sizeof(struct foo) would return 16, even if the actual content > occupies 9 bytes only. That's because the largest basic element is u64 > i.e. 8 bytes. Normally this trailing padding is not an issue, unless > you have an array of such a struct or if it is a member of another > struct. If you want to get rid of that padding, you need to use > __packed again (which of course would make all subsequent instances of > that structure in your array completely misaligned too). > > Two odd exceptions with the old ABI on ARM: > > - The alignment of a 64-bit value is always 4 bytes not 8. > > - The size of all structures are always rounded up to a 4-byte boundary, > irrespective of their content. > > If you fall into none of the above issues, then you don't need any > __packed, period. We don't fall into any of these cases, and therefore as you say, we don't need packed. Arnd and I have both explained this. So why do you keep arguing that we do need it? Alan Stern -- 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/