All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.