Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Hannes Reinecke [mailto:hare@xxxxxxx]
> Sent: Wednesday, November 02, 2011 2:21 AM
> To: dm-devel@xxxxxxxxxx
> Subject: Re:  [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@xxxxxxxxxx>
> > ---
> >
> > --- 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.

> 
> Cheers,
> 
> Hannes
> --
> Dr. Hannes Reinecke		      zSeries & Storage
> hare@xxxxxxx			      +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)
> 
> --
> dm-devel mailing list
> dm-devel@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux