Messages in this thread | | | Date | Tue, 29 Jun 2004 09:12:46 +0200 | From | Vojtech Pavlik <> | Subject | Re: drivers/block/ub.c |
| |
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/
| |