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
next prev parent 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