[dm-devel] [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
Hannes Reinecke
hare at suse.de
Wed Nov 2 15:33:49 UTC 2011
On 11/02/2011 04:23 PM, Moger, Babu wrote:
>> -----Original Message-----
>> From: Hannes Reinecke [mailto:hare at suse.de]
>> Sent: Wednesday, November 02, 2011 2:21 AM
>> To: dm-devel at redhat.com
>> Subject: Re: [dm-devel] [PATCH 3/4] scsi_dh_rdac: Adding the match
>> function for rdac device handler
>>
>> On 11/01/2011 06:19 PM, Moger, Babu wrote:
>>> This patch introduces the match function for rdac device handler.
>> Without this,
>>> sometimes handler attach fails during the device_add. The match
>> function was
>>> introduced by this patch
>>> http://www.spinics.net/lists/linux-scsi/msg54284.html
>>>
>>> Signed-off-by: Babu Moger<babu.moger at netapp.com>
>>> ---
>>>
>>> --- linux/drivers/scsi/device_handler/scsi_dh_rdac.c.orig 2011-10-31
>> 11:25:44.000000000 -0500
>>> +++ linux/drivers/scsi/device_handler/scsi_dh_rdac.c 2011-10-31
>> 11:31:34.000000000 -0500
>>> @@ -819,6 +819,21 @@ static const struct scsi_dh_devlist rdac
>>> {NULL, NULL},
>>> };
>>>
>>> +static bool rdac_match(struct scsi_device *sdev)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; rdac_dev_list[i].vendor; i++) {
>>> + if (!strncmp(sdev->vendor, rdac_dev_list[i].vendor,
>>> + strlen(rdac_dev_list[i].vendor))&&
>>> + !strncmp(sdev->model, rdac_dev_list[i].model,
>>> + strlen(rdac_dev_list[i].model))) {
>>> + return true;
>>> + }
>>> + }
>>> + return false;
>>> +}
>>> +
>>> static int rdac_bus_attach(struct scsi_device *sdev);
>>> static void rdac_bus_detach(struct scsi_device *sdev);
>>>
>>> @@ -831,6 +846,7 @@ static struct scsi_device_handler rdac_d
>>> .attach = rdac_bus_attach,
>>> .detach = rdac_bus_detach,
>>> .activate = rdac_activate,
>>> + .match = rdac_match,
>>> };
>>>
>>> static int rdac_bus_attach(struct scsi_device *sdev)
>>>
>> As stated in the other mail, I guess we would need to have a check
>> if the LUN is in ALUA mode.
>> And, btw, the _original_ intention was to allow vendor-specific
>> device_handler to do some better probing, eg querying some
>> vendor-specific VPD pages.
>> Especially for RDAC it would make far more sense to query the
>> existence and format of one of the RDAC-specific VPD pages (eg 0xC2,
>> 0xC4, or 0xC8) and use that for matching.
>> Then you could do away with the vendor/model array altogether here
>> and we wouldn't need to update the rdac handler every time a new
>> array comes out or has been rebranded by some OEM.
>
> OK. I will add the check for TPGS. I will send the patches tomorrow.
> For sending the VPD pages(0xC2, 0xC4 and 0xC8), I think we need be
> little careful here.
> This includes sending these commands to every possible device in the
> system. That is what we want to avoid.
> I will investigate more on that. That will be my next set of patches
> independent of this.
>
Fair enough.
As long as it's understood to be an interim solution, then we would
only need to check for the TGPS bit.
Which has the neat side-effect that we don't actually have to do any
I/O to check this, as the information is already present at that time.
While you're at it, could you please add this check for scsi_dh_emc,
too?
The Clariion is also able to run in dual-mode, so the same check is
required there, too.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare at suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
More information about the dm-devel
mailing list