From: Douglas Gilbert <dougg@torque.net>
To: Jeremy Higdon <jeremy@sgi.com>
Cc: Matthew Wilcox <willy@debian.org>, Christoph Hellwig <hch@lst.de>,
Emoore@lsil.com, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] sg.c to set direction more reliably (was Re: [PATCH] fusion update to current APIs)
Date: Tue, 15 Jun 2004 16:47:11 +1000 [thread overview]
Message-ID: <40CE9B6F.8000301@torque.net> (raw)
In-Reply-To: <20040615060811.GA178857@sgi.com>
Jeremy Higdon wrote:
> Okay, here's my proposed patch to sg.
>
> If it's able to determine the direction based on the input and output
> buffer sizes, it uses those. If both input and output buffer sizes
> are non-zero, then it resorts to the command bytes. Folks familiar
> with the mptscsi driver will recognize the sg_direction function :-)
>
> I've tested this using sg_utils, and it seems to work, but those are
> probably well-behaved. I will endeavor to test tomorrow with some
> RAID utilities that have not been well-behaved, in conjunction with
> removing the direction-override code from the host driver.
>
> If this works, then we can remove the nasty direction code from all
> the host drivers.
>
> jeremy
So I guess this patch only applies to sg_header usage since the
users of sg_io_hdr (including SG_IO ioctl users) must explicitly
give the data direction.
> ===== drivers/scsi/sg.c 1.90 vs edited =====
> --- 1.90/drivers/scsi/sg.c Sat May 29 10:57:23 2004
> +++ edited/drivers/scsi/sg.c Mon Jun 14 22:36:55 2004
> @@ -480,6 +480,61 @@
> return (0 == err) ? count : err;
> }
>
> +
> +static int
> +sg_direction(char *cmnd)
> +{
> + switch (cmnd[0]) {
> + /* _DATA_OUT commands */
> + case WRITE_6: case WRITE_10: case WRITE_12:
> + case WRITE_16:
> + case WRITE_LONG: case WRITE_SAME: case WRITE_BUFFER:
> + case WRITE_VERIFY: case WRITE_VERIFY_12:
> + case COMPARE: case COPY: case COPY_VERIFY:
> + case SEARCH_EQUAL: case SEARCH_HIGH: case SEARCH_LOW:
> + case SEARCH_EQUAL_12: case SEARCH_HIGH_12: case SEARCH_LOW_12:
> + case MODE_SELECT: case MODE_SELECT_10: case LOG_SELECT:
> + case SEND_DIAGNOSTIC: case CHANGE_DEFINITION: case UPDATE_BLOCK:
> + case SET_WINDOW: case MEDIUM_SCAN: case SEND_VOLUME_TAG:
> + case REASSIGN_BLOCKS:
> + case PERSISTENT_RESERVE_OUT:
> + case 0xea:
Perhaps you might like to tell us what the 0xea vendor
specific command is (for the record)?
> + case 0xa3:
and 0xa3 is MAINTENANCE IN which would be ..._FROM_DEV .
Did you mean 0xa4 (MAINTENANCE OUT)?
> + return SG_DXFER_TO_DEV;
> +
> + /* No data transfer commands */
> + case SEEK_6: case SEEK_10:
> + case RESERVE: case RELEASE:
> + case TEST_UNIT_READY:
> + case START_STOP:
> + case ALLOW_MEDIUM_REMOVAL:
> + return SG_DXFER_NONE;
> +
> + /* Conditional data transfer commands */
> + case FORMAT_UNIT:
> + if (cmnd[1] & 0x10) /* FmtData (data out phase)? */
> + return SG_DXFER_TO_DEV;
> + else
> + return SG_DXFER_NONE;
> +
> + case VERIFY:
> + if (cmnd[1] & 0x02) /* VERIFY:BYTCHK (data out phase)? */
> + return SG_DXFER_TO_DEV;
> + else
> + return SG_DXFER_NONE;
> +
> + case RESERVE_10:
> + if (cmnd[1] & 0x03) /* RESERVE:{LongID|Extent} (data out phase)? */
> + return SG_DXFER_TO_DEV;
> + else
> + return SG_DXFER_NONE;
> +
> + /* Must be data _IN! */
> + default:
> + return SG_DXFER_FROM_DEV;
> + }
> +}
> +
> static ssize_t
> sg_write(struct file *filp, const char __user *buf, size_t count, loff_t * ppos)
> {
> @@ -552,11 +607,6 @@
> hp->cmd_len = (unsigned char) cmd_size;
> hp->iovec_count = 0;
> hp->mx_sb_len = 0;
> - if (input_size > 0)
> - hp->dxfer_direction = (old_hdr.reply_len > SZ_SG_HEADER) ?
> - SG_DXFER_TO_FROM_DEV : SG_DXFER_TO_DEV;
> - else
> - hp->dxfer_direction = (mxsize > 0) ? SG_DXFER_FROM_DEV : SG_DXFER_NONE;
> hp->dxfer_len = mxsize;
> hp->dxferp = (char __user *)buf + cmd_size;
> hp->sbp = NULL;
> @@ -566,6 +616,18 @@
> hp->usr_ptr = NULL;
> if (__copy_from_user(cmnd, buf, cmd_size))
> return -EFAULT;
> + /*
> + * If data direction is indeterminate because both input and output size
> + * are greater than 0, use command bytes to determine direction.
> + */
> + if (input_size == 0 && mxsize > 0)
> + hp->dxfer_direction = SG_DXFER_FROM_DEV;
> + else if (input_size > 0 && mxsize == 0)
> + hp->dxfer_direction = SG_DXFER_TO_DEV;
> + else if (input_size == 0 && mxsize == 0)
> + hp->dxfer_direction = SG_DXFER_NONE;
> + else
> + hp->dxfer_direction = sg_direction(cmnd);
> k = sg_common_write(sfp, srp, cmnd, sfp->timeout, blocking);
> return (k < 0) ? k : count;
> }
> -
Doug Gilbert
next prev parent reply other threads:[~2004-06-15 6:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-31 11:52 [PATCH] fusion update to current APIs Christoph Hellwig
2004-06-12 0:36 ` Jeremy Higdon
2004-06-12 3:45 ` Matthew Wilcox
2004-06-12 5:13 ` Jeremy Higdon
2004-06-12 5:20 ` Matthew Wilcox
2004-06-15 6:08 ` [PATCH] sg.c to set direction more reliably (was Re: [PATCH] fusion update to current APIs) Jeremy Higdon
2004-06-15 6:47 ` Douglas Gilbert [this message]
2004-06-15 7:41 ` Jeremy Higdon
2004-06-15 15:07 ` Jeff Garzik
2004-06-15 21:34 ` Jeremy Higdon
2004-06-15 22:10 ` Jeff Garzik
2004-06-15 22:15 ` Jeremy Higdon
2004-08-26 7:09 ` Jeremy Higdon
2004-08-26 8:44 ` Douglas Gilbert
2004-08-27 1:12 ` Jeremy Higdon
2004-08-27 8:10 ` Jeremy Higdon
2004-08-28 5:08 ` Douglas Gilbert
2004-08-28 9:39 ` Jeremy Higdon
2004-08-30 7:08 ` [PATCH] sg.c to warn about ambiguous data direction Jeremy Higdon
2004-06-15 6:54 ` [PATCH] sg.c to set direction more reliably (was Re: [PATCH] fusion update to current APIs) Jeff Garzik
2004-06-15 7:50 ` Jeremy Higdon
2004-06-15 7:57 ` Arjan van de Ven
2004-06-15 8:40 ` Jeremy Higdon
2004-06-15 8:17 ` Christoph Hellwig
2004-06-15 8:48 ` Jeremy Higdon
2004-06-15 9:10 ` Jeremy Higdon
2004-06-15 9:31 ` Jeremy Higdon
2004-06-15 17:42 ` Patrick Mansfield
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=40CE9B6F.8000301@torque.net \
--to=dougg@torque.net \
--cc=Emoore@lsil.com \
--cc=hch@lst.de \
--cc=jeremy@sgi.com \
--cc=linux-scsi@vger.kernel.org \
--cc=willy@debian.org \
/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