On Wed, 2008-05-21 at 08:18 +0200, Hannes Reinecke wrote: > Chandra Seetharaman wrote: > > Hi Hannes, > > > > Now I see why you want this change in dm-multipath. I think I agree with > > these changes. > > > Ah. good. > > > But, it brings another question: what does dh_state provide ? Help to > > user to see which hardware handler a device is attached to ? > > > And allowing to attach to a different hardware handler. > Not everyone is running multipathing, but might be interested in the > having the device handler nevertheless. > > > I thought more about the scsi_dh_detach function (in the context of my > > earlier comment), adding it would require more housekeeping to associate > > one-to-one mapping between attach and detach. We can leave it the same > > way as the module will be detached when the device disappear eventually. > > > Why? You can detach with dh_state, too; just do an > > echo detach > /sys/block/sdX/device/dh_state > > and the hardware handler will detach. > So no additional attribute is required. Actually, if you're going down this route, it makes more sense to have the device handler be a driver ... remember you were the one promising multiple driver binding at the FS/Storage summit ... that way we can use all the generic driver standard interfaces for manual binding/unbinding. Plus we can place the attributes as driver attribute groups. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
