From: Pete Zaitcev <zaitcev@redhat.com>
To: Mikael Pettersson <mikpe@csd.uu.se>
Cc: rmk+lkml@arm.linux.org.uk, linux-kernel@vger.kernel.org,
linux-usb-devel@lists.sourceforge.net, oliver@neukum.org,
zaitcev@redhat.com
Subject: Re: need for packed attribute
Date: Thu, 12 Jan 2006 09:20:06 -0800 [thread overview]
Message-ID: <20060112092006.6a9f4509.zaitcev@redhat.com> (raw)
In-Reply-To: <200601121227.k0CCRCB8016162@alkaid.it.uu.se>
On Thu, 12 Jan 2006 13:27:12 +0100 (MET), Mikael Pettersson <mikpe@csd.uu.se> wrote:
> [...] Do you have any
> information about why gcc is doing this on ARM/Linux?
Russell forgot to explain it, but the reason for this weirdness is real.
It is so you can do things like this:
struct foo {
char x, y;
};
struct bar {
long g;
};
char *p;
struct bar *bp;
p = kmalloc(sizeof(struct foo)+sizeof(struct bar));
bp = p + sizeof(struct foo);
Notice that sizes are aligned even in sensible ABIs whenever you
have anything bigger than a char inside a struct, in order to let
arrays of structures work properly. As a side effect, the construct
above would be aligned whenever struct foo contained a long. So most
of the time we see the same result, ARM or not.
So this is not really a question of whatever some silly document
specifies, but what is workable in real life C programming.
Funnily enough, you are not safe depending on the ABI to make this
sort of padding (so our favourite alloc_netdev() and alloc_ieee80211
only work by accident with the trailing u8 priv[]). For example, on
sparc(32) the ABI alignes to 32 bits only, but the ldd instruction
traps if a 64-bit value is not aligned to 64 bits, so if the struct
bar in the above example had a long long, it would still trap.
Another funny thing about the above is that once you mark struct foo
packed, the example breaks. So, nobody should do use packed structs
in such constructs ... unless everything is packed. The pack attribute
has significant properties of cancer.
-- Pete
P.S. I am repeating myself as Katon, but I am yet to see why any of
this matters. Neither Russell nor Oliver ever presented a case where
an unpacked struct caused breakage in USB.
P.P.S. The USB stack was careful to use correct sizes historically.
One grep of the source will tell you that all this stench emanates from
the newer code, in particular the gadget and its attendant components,
such as usbtest. Guess who wrote it: same gentleman who advocated adding
((packed)) to _all_ structures "used to talk to hardware". He just has
no respect for coding practices, that's all. And some other gentleman,
otherwise highly respected for his sharp eye for races and locking
problems, is only too happy to copy-paste and to forward patches which
offer no justification.
next prev parent reply other threads:[~2006-01-12 17:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-12 12:27 need for packed attribute Mikael Pettersson
2006-01-12 13:47 ` Russell King
2006-01-12 13:53 ` Russell King
2006-01-12 16:30 ` Mikael Pettersson
2006-01-12 16:46 ` Russell King
2006-01-12 17:22 ` [linux-usb-devel] " David Vrabel
2006-01-12 17:34 ` Russell King
2006-01-12 17:20 ` Pete Zaitcev [this message]
2006-01-12 17:26 ` Russell King
2006-01-12 17:36 ` Pete Zaitcev
2006-01-12 19:35 ` [linux-usb-devel] " David Brownell
-- strict thread matches above, loose matches on Subject: below --
2006-01-06 18:15 Oliver Neukum
2006-01-06 18:38 ` Russell King
2006-01-12 18:32 ` Benjamin LaHaise
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060112092006.6a9f4509.zaitcev@redhat.com \
--to=zaitcev@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mikpe@csd.uu.se \
--cc=oliver@neukum.org \
--cc=rmk+lkml@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox