public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Chandra Seetharaman <sekharan@us.ibm.com>
Cc: device-mapper development <dm-devel@redhat.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-scsi@vger.kernel.org
Subject: Re: [dm-devel] [PATCH 2/7] scsi_dh: Add 'dh_state' sysfs attribute
Date: Fri, 23 May 2008 13:23:58 +0200	[thread overview]
Message-ID: <20080523112358.GE380@pentland.suse.de> (raw)
In-Reply-To: <1211508500.21974.503.camel@chandra-ubuntu>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 4111 bytes --]

On Thu, May 22, 2008 at 07:08:20PM -0700, Chandra Seetharaman wrote:
> 
> On Tue, 2008-05-20 at 16:05 +0200, Hannes Reinecke wrote:
> > Implement a 'dh_state' sdev attribute for dynamic device handler
> > manipulation. A read on the attribute will return the name of
> > the currently attached device handler or 'detached' if no handler
> > is attached.
> > The attribute allows the following strings to be written:
> > - The name of the device handler to be attached if the state is
> >   'detached'.
> > - 'activate' to trigger path activation if a device handler
> >   is attached.
> > - 'detach' to detach the currently attached device handler.
> > 
> > Signed-off-by: Hannes Reinecke <hare@suse.de>
> > ---
> >  drivers/scsi/device_handler/scsi_dh.c |  107 ++++++++++++++++++++++++++++++++-
> >  1 files changed, 105 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/scsi/device_handler/scsi_dh.c b/drivers/scsi/device_handler/scsi_dh.c
> > index 0b5c457..b80fae7 100644
> > --- a/drivers/scsi/device_handler/scsi_dh.c
> > +++ b/drivers/scsi/device_handler/scsi_dh.c
> > @@ -79,6 +79,98 @@ static void scsi_dh_handler_detach(struct scsi_device *sdev)
> >  }
> > 
> >  /*
> > + * Functions for sysfs attribute 'dh_state'
> > + */
> > +static ssize_t
> > +store_dh_state(struct device *dev, struct device_attribute *attr,
> > +	       const char *buf, size_t count)
> > +{
> > +	struct scsi_device *sdev = to_scsi_device(dev);
> > +	struct scsi_device_handler *scsi_dh;
> > +	int err = -EINVAL;
> > +
> > +	if (!sdev->scsi_dh_data) {
> > +		/*
> > +		 * Attach to a device handler
> > +		 */
> > +		if (!(scsi_dh = get_device_handler(buf)))
> > +			return err;
> > +		err = scsi_dh_handler_attach(sdev, scsi_dh);
> > +	} else {
> > +		if (!strncmp(buf, "detach", 6)) {
> > +			/*
> > +			 * Detach from a device handler
> > +			 */
> > +			scsi_dh_handler_detach(sdev);
> > +			err = 0;
> > +		} else if (!strncmp(buf, "activate", 8)) {
> > +			/*
> > +			 * Activate a device handler
> > +			 */
> > +			scsi_dh = sdev->scsi_dh_data->scsi_dh;
> > +			if (scsi_dh->activate)
> > +				err = scsi_dh->activate(sdev);
> > +			else
> > +				err = 0;
> 
> Sorry for the late comment. Why do we want to give the user to be able
> to activate a path ? (I am assuming user as we do not want to be calling
> this from multipath tools).
> 
This is quite a handy feature if you want to test failover manually (ie
if the commands are being sent correctly and the array reacts properly).
And, of course, there might be scenarios where you'd want to trigger
a failover manually.

[ .. ]
> > @@ -114,14 +206,19 @@ static int scsi_dh_notifier(struct notifier_block *nb,
> >  		goto out;
> > 
> >  	if (action == BUS_NOTIFY_ADD_DEVICE) {
> > +		int err;
> > +
> >  		err = scsi_dh_handler_attach(sdev, devinfo);
> > +		if (!err)
> > +			err = device_create_file(dev, &scsi_dh_state_attr);
> 
> we don't want to detach when we fail creating the file ? I am ok with
> it, but just wanted to make sure that is what you intended.
> 
The 'dh_state' attribute is just an add-on and not necessary for proper
functionality. So I thought we could just ignore this error.
But seeing that this indicates some general error condition it's probably
better to at least return this error.

> >  	} else if (action == BUS_NOTIFY_DEL_DEVICE) {
> >  		if (sdev->scsi_dh_data == NULL)
> >  			goto out;
> > +		device_remove_file(dev, &scsi_dh_state_attr);
> >  		scsi_dh_handler_detach(sdev);
> >  	}
> >  out:
> > -	return err;
> > +	return 0;
> 
> why are we not returning err ?
See above. 

Fixed in the scsi_dh branch.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2008-05-23 11:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-20 14:05 [PATCH 2/7] scsi_dh: Add 'dh_state' sysfs attribute Hannes Reinecke
2008-05-23  2:08 ` [dm-devel] " Chandra Seetharaman
2008-05-23 11:23   ` Hannes Reinecke [this message]

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=20080523112358.GE380@pentland.suse.de \
    --to=hare@suse.de \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sekharan@us.ibm.com \
    /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