public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
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

  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