Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758281AbXFFIvZ (ORCPT ); Wed, 6 Jun 2007 04:51:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754311AbXFFIvQ (ORCPT ); Wed, 6 Jun 2007 04:51:16 -0400 Received: from canuck.infradead.org ([209.217.80.40]:59069 "EHLO canuck.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752896AbXFFIvO (ORCPT ); Wed, 6 Jun 2007 04:51:14 -0400 Subject: Re: [Patch 04/18] include/linux/logfs.h From: David Woodhouse To: Segher Boessenkool Cc: Kyle Moffett , John Stoffel , Willy Tarreau , Evgeniy Polyakov , CaT , Ondrej Zajicek , linux-kernel@vger.kernel.org, Bill Davidsen , Jan Engelhardt , Thomas Gleixner , Dongjun Shin , Pekka Enberg , Arnd Bergmann , Albert Cahalan , linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org, Artem Bityutskiy , Sam Ravnborg , Jamie Lokier , Roland Dreier , =?ISO-8859-1?Q?J=F6rn?= Engel , Pavel Machek , Ulisses Furquim , akpm@osdl.org, David Weinehall In-Reply-To: References: <20070603183845.GA8952@lazybastard.org> <20070603184205.GE8952@lazybastard.org> <200706032342.27252.arnd@arndb.de> <20070604091245.GF14823@lazybastard.org> <1180964303.25232.358.camel@pmac.infradead.org> <18f622d94e9273fe6c93ef091fcec87c@kernel.crashing.org> <1181058836.16089.23.camel@hades.cambridge.redhat.com> Content-Type: text/plain Date: Wed, 06 Jun 2007 09:50:20 +0100 Message-Id: <1181119820.25232.434.camel@pmac.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-17.fc7.dwmw2.1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by canuck.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2174 Lines: 51 On Tue, 2007-06-05 at 20:49 +0200, Segher Boessenkool wrote: > >>> It would be better if GCC had a 'nopadding' attribute which gave us > >>> what we need without the _extra_ implications about alignment. > >> > >> That's impossible; removing the padding from a struct > >> _will_ make accesses to its members unaligned (think > >> about arrays of that struct). > > > > It _might_ make accesses to _some_ of its members unaligned. > > It _will_ make accesses to _at least one_ of the members > unaligned, in the second array element. It _might_, but not necessarily. Won't a simple struct { uint16_t } get padded to a size of 4 bytes on ARM? Even if I'm misremembering that, I certainly can't guarantee that such a thing will _never_ happen on any newly-invented ABI. If you had 'nopadding' instead of 'packed', then there's no need to emit code to handle unaligned loads. Likewise, with a struct which looks like this: { uint32_t, uint16_t, uint16_t, uint32_t, uint32_t } I cannot _guarantee_ that there will never be an architecture on which we'll end up using 32 bits of space for each uint16_t. I might _guess_ that and hope, but that's precisely the kind of moronic empirical behaviour which caused Linux to have so many problems with newer compilers in the past. If it isn't _guaranteed_ then I shouldn't be assuming it. Thus, I want a way to tell the compiler not to insert _any_ padding. But without the compiler making extra inferences about the whole thing being found at arbitrary alignments. And if I had something like this (which is admittedly contrived, but hardware people _do_ do stupid things to us): { uint32_t, uint8_t, uint16_t, uint8_t, uint32_t, uint32_t } With the 'packed' attribute the compiler would assume arbitrary alignment of all the 32-bit integers. But in reality it's only necessary for the uint16_t in the middle. A 'nopadding' attribute would deal with that correctly. -- dwmw2 - 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/