From: David Brownell <david-b@pacbell.net>
To: linux-usb-devel@lists.sourceforge.net
Cc: Pete Zaitcev <zaitcev@redhat.com>,
Mikael Pettersson <mikpe@csd.uu.se>,
rmk+lkml@arm.linux.org.uk, linux-kernel@vger.kernel.org,
oliver@neukum.org
Subject: Re: [linux-usb-devel] Re: need for packed attribute
Date: Thu, 12 Jan 2006 11:35:37 -0800 [thread overview]
Message-ID: <200601121135.38210.david-b@pacbell.net> (raw)
In-Reply-To: <20060112092006.6a9f4509.zaitcev@redhat.com>
On Thursday 12 January 2006, Pete Zaitcev wrote (in another snide postscript):
>
> 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.
You were the one who said "talk to hardware", as I had politely pointed
out off-line in previous email ... nobody else.
What you've done a couple times now is try to put those words in someone
else's mouth -- mine! -- which are clearly both (a) not what were actually
said, and (b) wrong. (FWIW it's something I've observed happening a lot
in the "traditional media" here in the US, it's not good there either.)
This what's known as not acting in good faith. "No respect for" ground
rules of discussion, for that matter ... if you're going to argue about
things, please don't put words in anyone's mouth. Certainly not mine.
(Even when the actual words said _are_ inconvenient to your agenda...)
The "packed" attribute is correct, since there's no guarantee that those
structures will be appearing in protocol data structures in GCC-friendly
layouts. Or even that the usb-if will generate protocol data structures
that happen to match GCC alignment rules, for that matter.
It's perfectly legal and common to have two seven-byte structures (like
non-audio endpoint descriptors) adjacent to each other, even when those
structures contain values otherwise subject to alignment restrictions (like
the maxpacket size, a __u16 value).
Moreover, there is no circumstance under which we'd want the compiler
expanding that seven byte data structure into an eight byte one, by
picking some place to insert a padding byte.
And for that matter, many/most of those protocol structures were declared
"packed" even in 2.4 kernels when Linux was extending them with host-side data
structures and making extra copies of them. The packing may have been
declared per-element rather than structure-wide, but it was still declared.
That's another way in which those comments of yours are wrong.
- Dave
prev parent reply other threads:[~2006-01-12 19:35 UTC|newest]
Thread overview: 11+ 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
2006-01-12 17:26 ` Russell King
2006-01-12 17:36 ` Pete Zaitcev
2006-01-12 19:35 ` David Brownell [this message]
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=200601121135.38210.david-b@pacbell.net \
--to=david-b@pacbell.net \
--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 \
--cc=zaitcev@redhat.com \
/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