From: Chandra Seetharaman <sekharan@us.ibm.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: dm-devel@redhat.com, linux-scsi@vger.kernel.org,
Mike Anderson <andmike@us.ibm.com>,
michaelc@cs.wisc.edu, jens.axboe@oracle.com, agk@redhat.com
Subject: Re: [PATCH 1/7] scsi_dh: add skeleton for SCSI Device Handlers
Date: Tue, 04 Mar 2008 14:25:56 -0800 [thread overview]
Message-ID: <1204669556.4963.138.camel@linuxchandra> (raw)
In-Reply-To: <1204666622.3091.86.camel@localhost.localdomain>
Thanks for your comments, James.
On Tue, 2008-03-04 at 15:37 -0600, James Bottomley wrote:
> On Wed, 2008-02-27 at 17:08 -0800, Chandra Seetharaman wrote:
> > Subject: scsi_dh: add skeleton for SCSI Device Handlers
> >
> > From: Chandra Seetharaman <sekharan@us.ibm.com>
> >
> > Add base support to the SCSI subsystem for SCSI device handlers.
>
> Generally, this is much cleaner and an easier implementation to follow,
> thanks.
Cool, thanks.
>
> > Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com>
> > Signed-off-by: Mike Anderson <andmike@linux.vnet.ibm.com>
> > Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
<snip>
> if (! scsi_command_normalize_sense(scmd, &sshdr))
> > @@ -306,6 +307,15 @@ static int scsi_check_sense(struct scsi_
> > if (scsi_sense_is_deferred(&sshdr))
> > return NEEDS_RETRY;
> >
> > + if (sdev->sdev_dh && sdev->sdev_dh->check_sense) {
> > + int rc;
> > +
> > + rc = sdev->sdev_dh->check_sense(sdev, &sshdr);
> > + if (rc != SUCCESS)
>
> I can see reasons for a sense handler to return SUCCESS to trigger a
> fast failure (say not ready needs initialising command or something, so
> this should be a specific sense handler doesn't care return code.
understand. I can return a NOT_HANDLED. Is it ok to add it as 0x2008 to
scsi.h ? or any suggestions.
>
> > + return rc;
> > + /* handler does not care. Drop down to default handling */
> > + }
> > +
> > /*
> > * Previous logic looked for FILEMARK, EOM or ILI which are
> > * mainly associated with tapes and returned SUCCESS.
> > Index: linux-2.6.25-rc2-mm1/include/scsi/scsi_device.h
> > ===================================================================
> > --- linux-2.6.25-rc2-mm1.orig/include/scsi/scsi_device.h
> > +++ linux-2.6.25-rc2-mm1/include/scsi/scsi_device.h
> > @@ -161,9 +161,25 @@ struct scsi_device {
> >
> > struct execute_work ew; /* used to get process context on put */
> >
> > + struct scsi_device_handler *sdev_dh;
> > + void *sdev_dh_data;
>
> This is a bit wasteful of 8 bytes ... why not simply move the
> sdev_dh_data inside the sdev_dh structure, then if there's no handler
> it's not occupying space?
There is one sdev_dh per handler, and one sdev_dh_data per device.
But, structures can be redefined to save space when there is no hardware
handler present. But, there will be a additional pointer dereference
while invoking the functions, is it ok ?
Here is what I am thinking:
--------
struct scsi_device_handler { }; /* same as now */
struct scsi_dh_data {
struct scsi_device_handler *sdev_dh;
char buf[0];
};
and the handlers will allocate appropriate size for this data structure.
struct scsi_device {
:
:
struct scsi_dh_data *scsi_dh_data;
};
all the function invocations will be like
sdev->scsi_dh_data->sdev_dh->activate,prep_fn,check_sense
------------
>
> > enum scsi_device_state sdev_state;
> > unsigned long sdev_data[0];
> > } __attribute__((aligned(sizeof(unsigned long))));
> >
<snip>
> +int scsi_dh_activate(struct request_queue *q)
> > +{
> > + int err = SCSI_DH_NOSYS;
> > + struct scsi_device *sdev;
> > + struct scsi_device_handler *sdev_dh;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(q->queue_lock, flags);
> > + sdev = q->queuedata;
> > + sdev_dh = sdev->sdev_dh;
> > + if (!sdev || !sdev_dh || !get_device(&sdev->sdev_gendev)) {
> > + spin_unlock_irqrestore(q->queue_lock, flags);
> > + goto done;
> > + }
> > + spin_unlock_irqrestore(q->queue_lock, flags);
>
> just on programming style, this is marginally better expressed as
>
> err = (!sdev || !sdev_dh || !get_device(&sdev->sdev_gendev)) ? SCSI_DH_NOSYS : 0;
> spin_unlock_irqrestore(q->queue_lock, flags);
>
> if (err)
> goto done; (or even return err)
>
> Just to eliminate the duplicate unlocks.
will do.
>
> > +
> > + if (sdev_dh->activate)
> > + err = sdev_dh->activate(sdev);
> > + put_device(&sdev->sdev_gendev);
> > +done:
> > + return err;
> > +}
> > +EXPORT_SYMBOL_GPL(scsi_dh_activate);
> >
<snip>
> +
> > +extern int scsi_dh_activate(struct request_queue *);
> > Index: linux-2.6.25-rc2-mm1/drivers/scsi/scsi_lib.c
> > ===================================================================
> > --- linux-2.6.25-rc2-mm1.orig/drivers/scsi/scsi_lib.c
> > +++ linux-2.6.25-rc2-mm1/drivers/scsi/scsi_lib.c
> > @@ -1156,6 +1156,11 @@ int scsi_setup_fs_cmnd(struct scsi_devic
> > struct scsi_cmnd *cmd;
> > int ret = scsi_prep_state_check(sdev, req);
> >
> > + if ((ret == BLKPREP_OK) && (req->cmd_type == REQ_TYPE_FS)) {
> > + if (sdev->sdev_dh && sdev->sdev_dh->prep_fn)
> > + ret = sdev->sdev_dh->prep_fn(sdev);
> > + }
> > +
> > if (ret != BLKPREP_OK)
> > return ret;
>
> This is the fastpath and we need to be careful. We already checked
> cmd_type == REQ_TYPE before calling scsi_setup_fs_cmnd(), so there's no
> need to check it again, surely.
Yeah, this was a cut-n-paste problem. I had this block at the higher
level, moved it here to get rid of that check, but forgot to remove
that :)
>
> Plus, since we're doing if (ret != BLKPREP_OK) just below this, if you
> move the if down below that, it can simply become
>
> if (unlikely(sdev->sdev_dh && sdev->sdev_dh->prep_fn)) {
> ret = sdev->sdev_dh->prep_fn(sdev);
> if (ret != BLKPREP_OK)
> return ret;
> }
>
> Because the two outer gates have already been checked. The unlikely
> expresses the fact that having device handlers isn't currently the very
> common case.
will do.
>
> Presumably the gcc optimiser would see all of this, but it never hurts
> to make sure.
>
> James
>
>
--
----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- sekharan@us.ibm.com | .......you may get it.
----------------------------------------------------------------------
next prev parent reply other threads:[~2008-03-04 22:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-28 1:08 [PATCH 0/7] Move hardware handlers from dm layer to SCSI layer Chandra Seetharaman
2008-02-28 1:08 ` [PATCH 1/7] scsi_dh: add skeleton for SCSI Device Handlers Chandra Seetharaman
2008-03-04 21:37 ` James Bottomley
2008-03-04 22:25 ` Chandra Seetharaman [this message]
2008-02-28 1:08 ` [PATCH 2/7] scsi_dh: add lsi rdac device handler Chandra Seetharaman
2008-02-28 1:08 ` [PATCH 3/7] scsi_dh: add hp sw " Chandra Seetharaman
2008-02-28 1:08 ` [PATCH 4/7] scsi_dh: add EMC Clariion " Chandra Seetharaman
2008-02-28 1:08 ` [PATCH 5/7] scsi_dh: Use SCSI device handler in dm-multipath Chandra Seetharaman
2008-02-28 1:09 ` [PATCH 6/7] scsi_dh: Remove hardware handlers from dm Chandra Seetharaman
2008-02-28 1:09 ` [PATCH 7/7] scsi_dh: Remove hardware handler infrastructure " Chandra Seetharaman
-- strict thread matches above, loose matches on Subject: below --
2008-03-11 1:33 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-03-11 1:33 ` [PATCH 1/7] scsi_dh: add skeleton for SCSI Device Handlers Chandra Seetharaman
2008-04-01 22:51 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-04-01 22:51 ` [PATCH 1/7] scsi_dh: add skeleton for SCSI Device Handlers Chandra Seetharaman
2008-04-16 1:18 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-04-16 1:18 ` [PATCH 1/7] scsi_dh: add skeleton for SCSI Device Handlers Chandra Seetharaman
2008-04-17 21:18 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-04-17 21:19 ` [PATCH 1/7] scsi_dh: add skeleton for SCSI Device Handlers Chandra Seetharaman
2008-04-17 22:22 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-04-17 22:22 ` [PATCH 1/7] scsi_dh: add skeleton for SCSI Device Handlers Chandra Seetharaman
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=1204669556.4963.138.camel@linuxchandra \
--to=sekharan@us.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=agk@redhat.com \
--cc=andmike@us.ibm.com \
--cc=dm-devel@redhat.com \
--cc=jens.axboe@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.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;
as well as URLs for NNTP newsgroup(s).