Messages in this thread | | | Date | Mon, 28 Jun 2004 13:25:31 -0700 | From | "David S. Miller" <> | Subject | Re: drivers/block/ub.c |
| |
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?"
I think it's bad to just "smack this attribute onto any structure that _MIGHT_ need it on some platform" I never do that in my drivers, and they work on all platforms. For example, if you have a simple DMA descriptor structure such as:
struct txd { u32 dma_addr; u32 length; };
It is just total and utter madness to put a packed or the proposed __nopadding__ attribute on that structure. Yet this seems to be what was suggested now and at the beginning of this thread. - 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/
| |