![]() | |||||||||||
Messages in this thread |
On Mon, Jun 28, 2004 at 01:25:31PM -0700, David S. Miller wrote: > On Mon, 28 Jun 2004 10:15:17 -0400 > Scott Wood <scott@timesys.com> wrote: > > > On Sun, Jun 27, 2004 at 02:26:28PM -0700, David S. Miller wrote: > > > On Sun, 27 Jun 2004 12:42:21 +0200 > > > Oliver Neukum <oliver@neukum.org> wrote: > > > > > > > OK, then it shouldn't be used in this case. However, shouldn't we have > > > > an attribute like __nopadding__ which does exactly that? > > > > > > It would have the same effect. CPU structure layout rules don't pack > > > (or using other words, add padding) exactly in cases where it is > > > needed to obtain the necessary alignment. > > > > No, it wouldn't, as you could drop the assumption that the base of > > the struct can be misaligned. Thus, the compiler only needs to > > generate unaligned loads and stores for fields which are unaligned > > within the struct, which in this case would be none of them. > > > > While it's rather unlikely that a struct like this one would ever > > need packing, it would help those structs that do need it by reducing > > the number of fields subjected to unaligned loads and stores. > > That's true. But if one were to propose such a feature to the gcc > guys, I know the first question they would ask. "If no padding of > the structure is needed, why are you specifying this new > __nopadding__ attribute?" You may have a struct, which itself might 'need' padding somewhere inside, however the structure start will always be aligned. Using __nopadding__ you should be much better off than using __packed_ in this case, because GCC can use the right aligned/nonaligned accesses for the members of the structure, because it knows which will be aligned and which not. -- Vojtech Pavlik SuSE Labs, SuSE CR - 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/ | ||||||||||
| Last update: 2005-03-22 14:04 [from the cache] ©2003-2008 | |||||||||||