From: Harvey Harrison <harvey.harrison@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH-mm] usb: file_storage use unaligned endian helpers rather than private versions
Date: Wed, 03 Dec 2008 14:33:06 -0800 [thread overview]
Message-ID: <1228343586.5412.115.camel@brick> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0812031615470.2181-100000@iolanthe.rowland.org>
On Wed, 2008-12-03 at 16:29 -0500, Alan Stern wrote:
> On Tue, 2 Dec 2008, Harvey Harrison wrote:
>
> > Use the new helpers for unaligned endian access. Make some small changes
> > to reading 24-bit lba values, read the full 32 bit value and mask. Produces
> > smaller and faster code on x86 and on powerpc.
> >
> > Coalesce some byte-writes in 32bit writes to allow byteswapping to happen
> > at compile time and become a 32-bit write without swapping if possible (x86
> > especially)
> >
> > This shrinks the size of file_storage.o by ~64 bytes on x86_32.
> >
> > Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
> > ---
> > Alan, what do you think?
>
> Well, it looks correct... but it's awfully ugly. Can't we keep the
> benefits of the new helpers while not messing the code up too much?
<snip>
> Suppose instead we do this:
>
> #define get_be16(buf) load_be16_noalign((be16 *) (buf))
> #define get_be24(buf) (load_be32_noalign((be32 *) (buf)) >> 8)
> #define get_be32(buf) load_be32_noalign((be32 *) (buf))
>
> #define put_be16(buf, val) store_be16_noalign((be16 *) (buf), val)
> #define put_be32(buf, val) store_be32_noalign((be32 *) (buf), val)
>
> Then almost no more changes would be needed, only the 24-bit
> consolidation stuff.
>
I'd rather the common functions just get used directly and cast as
necessary...but it's your code. Or define a few generic structs
and get a pointer to those and get typechecking for free.
> > @@ -1583,9 +1552,9 @@ static int do_read(struct fsg_dev *fsg)
> > /* Get the starting Logical Block Address and check that it's
> > * not too big */
> > if (fsg->cmnd[0] == SC_READ_6)
> > - lba = (fsg->cmnd[1] << 16) | get_be16(&fsg->cmnd[2]);
> > + lba = load_be32_noalign((__be32 *)&fsg->cmnd[0]) & 0xffffff;
>
> Like this, which would become
>
> lba = get_be24(&fsg->cmnd[1]);
Again, I could live with it, but would suggest just coding it directly and
maybe just add a comment that this really only wants 24 bits (I thought it was 21 bits,
but then again, I know next to squat about scsi). <shrug>
>
> > @@ -2126,9 +2095,9 @@ static int do_request_sense(struct fsg_dev *fsg, struct fsg_buffhd *bh)
> > static int do_read_capacity(struct fsg_dev *fsg, struct fsg_buffhd *bh)
> > {
> > struct lun *curlun = fsg->curlun;
> > - u32 lba = get_be32(&fsg->cmnd[2]);
> > + u32 lba = load_be32_noalign((__be32 *)&fsg->cmnd[2]);
> > int pmi = fsg->cmnd[8];
> > - u8 *buf = (u8 *) bh->buf;
> > + __be32 *buf = (__be32 *)bh->buf;
> >
> > /* Check the PMI and LBA fields */
> > if (pmi > 1 || (pmi == 0 && lba != 0)) {
> > @@ -2136,8 +2105,8 @@ static int do_read_capacity(struct fsg_dev *fsg, struct fsg_buffhd *bh)
> > return -EINVAL;
> > }
> >
> > - put_be32(&buf[0], curlun->num_sectors - 1); // Max logical block
> > - put_be32(&buf[4], 512); // Block length
> > + store_be32_noalign(&buf[0], curlun->num_sectors - 1); // Max logical block
> > + store_be32_noalign(&buf[1], 512); // Block length
> > return 8;
> > }
> >
>
> I don't like these changes. You've gone from an array of bytes to an
> array of 32-bit words, which doesn't agree with the data structures
> defined in the SCSI specification. Besides, with my new macros this
> isn't needed.
OK, if you'd rather keep the array-of-bytes and use the offsets method,
that's fine too.
Something like (is this really so bad?):
store_be32_noalign((__be32 *)&buf[0], curlun->num_sectors - 1);
store_be32_noalign((__be32 *)&buf[4], 512);
> What do you think?
Personally I don't think it's that ugly just using the common functions
directly. BTW, note that if you know the alignment, there are aligned versions
coming as well. YMMV.
Harvey
next prev parent reply other threads:[~2008-12-03 22:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-03 2:23 [RFC PATCH-mm] usb: file_storage use unaligned endian helpers rather than private versions Harvey Harrison
2008-12-03 21:29 ` Alan Stern
2008-12-03 22:33 ` Harvey Harrison [this message]
2008-12-04 15:07 ` Alan Stern
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=1228343586.5412.115.camel@brick \
--to=harvey.harrison@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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