public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-scsi@vger.kernel.org
Subject: Re: What's the state of sdev->tagged_queue
Date: Fri, 06 Jun 2003 10:04:50 -0400	[thread overview]
Message-ID: <3EE09F82.2060000@redhat.com> (raw)
In-Reply-To: <20030606074813.GA18748@lst.de>

Christoph Hellwig wrote:
> Hi Doug,

Hi Christoph.

> scsi_ioctl.c has the following comment from you:
> 
>  * The next two ioctls either need to go or need to be changed to
>  * pass tagged queueing changes through the low level drivers.
>  * Simply enabling or disabling tagged queueing without the knowledge
>  * of the low level driver is a *BAD* thing.
> 
> and scsi.h has this:
> 
>  unsigned tagged_queue:1;/* This is going away!!!!  Look at simple_tags
>                             instead!!!  Please fix your driver now!! */
> 
> but several drivers still look at it although it's never touched
> outside scsi_ioctl.c and the individual drivers.  Most drivers uses also
> look pretty bogus.  Can we just the ioctls and the field?

I assume that should read "Can we just kill the ioctls and the field?" :-)

The answer to that is yes I think.  The ioctls for certain, the field 
I'm pretty sure of.  Originally, the field was used as a boolean that 
was when we enabled tagged queueing on a device.  Now, a value of 
simple_tags > 1 should do the same thing.  However, due to usage of 
cmd_per_lun on both tagged and untagged devices (I would have to check 
this, I'm a bit out of touch since my accident) may cause confusion.  If 
we set queue depth to cmd_per_lun the device may look tagged when it is 
in fact not tagged.  The replacement test may need to be if simple_tags 
 > cmd_per_lun to indicate true tagged queueing.


> 53c700.c:	if(SCp->device->tagged_supported && !SCp->device->tagged_queue

This is checking that tagged queueing is supported and not already 
enabled (a holdover from the fact that select_queue_depths would get 
called more than once on a single device if we ever had a scsi 
add-single-device command after the initial device scan).

> AM53C974.c:				if (!hostdata->connected->device->tagged_queue)

Tests tagged queueing not active on a device.

> AM53C974.c:			    cmd->device->tagged_queue = 0;

Disabling tagged queueing on a device.

> AM53C974.c:	if (cmd->device->tagged_queue && (tag != TAG_NONE)) {

Checking for a tagged device with an untagged command.  Others are all 
similar.

> NCR5380.c:						cmd->device->tagged_queue = 0;
> arm/acornscsi.c:	if (SCpnt->device->tagged_queue) {
> arm/acornscsi.c:	    host->SCpnt->device->tagged_queue = 0;
> arm/acornscsi.c:			     scd->tagged_queue ? "en" : "dis",
> arm/fas216.c:	if (SCpnt->device->tagged_queue && SCpnt->cmnd[0] != REQUEST_SENSE &&
> arm/fas216.c:				     scd->tagged_queue ? "en" : "dis",
> ncr53c8xx.c:	if (lp && !lp->numtags && cmd->device && cmd->device->tagged_queue) {
> qla1280.c:			if (cmd->device->tagged_queue)
> qla1280.c:			if (cmd->device->tagged_queue)
> scsi.h:	unsigned tagged_queue:1;/* This is going away!!!!  Look at simple_tags
> scsi_ioctl.c:		sdev->tagged_queue = 1;
> scsi_ioctl.c:		sdev->tagged_queue = 0;
> sym53c8xx.c:	if (lp && !lp->numtags && cmd->device && cmd->device->tagged_queue) {

This does bring up another issue I've been thinking about though so I'll 
suggest it now.

Currently, we use the value of host->this_id to skip the scsi device of 
the host controller in our device scan.  What I would like to do is 
create an sg device entry for this_id that is type processor, is a fake 
device, that implements whatever ioctls at the mid layer level that are 
appropriate, but that also allow the low level driver to register a fall 
through host ioctl routine that can be attached to this device.  This 
would give us a uniform method of accessing host controllers via the 
scsi subsystem.  Generic ioctls that can be handled in the mid layer can 
be done so.  Host adapter specific ioctls can then be handled by the 
driver.  At least this way we wouldn't have to have a different /proc 
method of doing these things in every single driver and we would be able 
to use a normal ioctl interface for things like controlling the various 
smart raid controllers, etc.  Thoughts?

-- 
   Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
            Red Hat, Inc.
            1801 Varsity Dr.
            Raleigh, NC 27606



  reply	other threads:[~2003-06-06 13:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-06  7:48 What's the state of sdev->tagged_queue Christoph Hellwig
2003-06-06 14:04 ` Doug Ledford [this message]
2003-06-06 14:19   ` Christoph Hellwig
2003-06-06 14:28     ` Doug Ledford

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=3EE09F82.2060000@redhat.com \
    --to=dledford@redhat.com \
    --cc=hch@lst.de \
    --cc=linux-scsi@vger.kernel.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