public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: sekharan@us.ibm.com
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-scsi@vger.kernel.org, dm-devel <dm-devel@redhat.com>
Subject: Re: [PATCH 1/7] scsi_dh: Implement generic device table handling
Date: Thu, 15 May 2008 09:16:56 +0200	[thread overview]
Message-ID: <482BE368.3070506@suse.de> (raw)
In-Reply-To: <1210819551.21974.252.camel@chandra-ubuntu>

Chandra Seetharaman wrote:
> On Wed, 2008-05-14 at 16:43 +0200, Hannes Reinecke wrote:
> <snip>
> 
>> +
>> +struct scsi_dh_devinfo_list {
>> +	struct list_head node;
>> +	char vendor[9];
>> +	char model[17];
>> +	struct scsi_device_handler *handler;
>> +};
> 
> I do not see why we should be duplicating the information that
> is already present in scsi_dh and is available here thru scsi_dh_list.
> Instead of walking thru the scsi_dh_dev_list we could walk thru
> scsi_dh_list and get the same result.
>
Indeed we can. I originally did this as it would allow us to dynamically
add and remove entries from that list, which isn't possible with the
static arrays provided by the individual device handler.
But seeing that we can now manually attach any device I guess we can
remove it.
 
> On the other hand, if we could create a cache of the list of devices
> (vendor-product-scsi_dh triplet) that has been attached, and walk
> thru that list first before others during attach, it would help
> (as we would guess there to be multiple of the same device).
>  
Yes, but we can achieve that very same thing by walking the scsi_dh_list.
I'll fix it up.

>> +
>> +int scsi_dh_handler_attach(struct scsi_device *sdev,
>> +			   struct scsi_device_handler *scsi_dh);
>> +int scsi_dh_handler_detach(struct scsi_device *sdev);
> 
> Why is the prototype needed ?
> 
> Can this be static ?
> 
Probably a left over from earlier attempts. Will be removing them.

>>  static struct scsi_device_handler *get_device_handler(const char *name)
>>  {
>> @@ -33,7 +45,7 @@ static struct scsi_device_handler *get_device_handler(const char *name)
>>
> 
> <snip>
> 
>> +/*
>> + * scsi_dh_handler_attach - Attach a device handler to a device
>> + * @sdev - SCSI device the device handler should attach to
>> + * @scsi_dh - The device handler to attach
>> + */
>> +int scsi_dh_handler_attach(struct scsi_device *sdev,
>> +			   struct scsi_device_handler *scsi_dh)
>> +{
>> +	int err = -EBUSY;
>> +
>> +	if (sdev->scsi_dh_data)
>> +		return err;
> 
> One of the later patch check for scsi_dh to be same as
> sdev->scsi_dh_data->scsi_dh. We can check for that here.
> 
> One more thing: there are multiple places (in this file and
> in the hardware handlers) the same check appear. Can we just
> do it only here and remove all the others ?
>
Yes. Will do.
 
>> +
>> +	err = scsi_dh->attach(sdev);
> 
> This assumes attach is available, but there is no assertion in
> scsi_register_device_handler().  Same is the case with detach(). Either
> assert or check for the function availability here.
Ok.

>> +
>> +	return err;
>> +}
>> +
>> +/*
>> + * scsi_dh_handler_detach - Detach a device handler to a device
>> + * @sdev - SCSI device the device handler should be detached from
>> + */
>> +int scsi_dh_handler_detach(struct scsi_device *sdev)
>> +{
>> +	struct scsi_device_handler *scsi_dh;
> 
> can avoid the variable and call detach directly ?
>> +
>> +	if (!sdev->scsi_dh_data)
>> +		return -ENODEV;
> 
> Can't we just return 0 ?
> 
Well, seeing that the actual detach callback is
of type 'void', we should be using the same type here.

>> +
>> +	scsi_dh = sdev->scsi_dh_data->scsi_dh;
>> +
>> +	scsi_dh->detach(sdev);
>> +
>> +	return 0;
>> +}
> 
> <snip>
> 
>>  	list_add(&scsi_dh->list, &scsi_dh_list);
>>  	spin_unlock(&list_lock);
>> +	bus_for_each_dev(&scsi_bus_type, NULL, scsi_dh, scsi_dh_notifier_add);
>> +	printk(KERN_INFO "%s: registered\n", scsi_dh->name);
> 
> We can be more descriptive. Like "Hardware handler %s registered" or some such.
> 
Ok.

>> +	ret = SCSI_DH_OK;
>>
>>  done:
>>  	return ret;
> <snip>
> 
>> +	}
>>  	list_del(&scsi_dh->list);
>>  	spin_unlock(&list_lock);
>> +	printk(KERN_INFO "%s: unregistered\n", scsi_dh->name);
> 
> Same here.
> 
OK.

Thanks for the review. I'll post an update soon.

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-15  7:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-14 14:43 [PATCH 1/7] scsi_dh: Implement generic device table handling Hannes Reinecke
2008-05-15  2:45 ` Chandra Seetharaman
2008-05-15  7:16   ` Hannes Reinecke [this message]
2008-05-16 18:32     ` 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=482BE368.3070506@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