On Thu, May 22, 2008 at 09:14:54AM +0100, James Bottomley wrote: > On Wed, 2008-05-21 at 08:18 +0200, Hannes Reinecke wrote: [ .. ] > > 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. > Hmm. Actually this very discussion I had with Kay Sievers earlier this week when we tried to make bsg useable for udev. The problem here is that we really want the device_handler to kick in _before_ any of the 'normal' SCSI ULD starts it's probing, as we might want to suppress I/O on this channel. If we were to use the normal driver binding for this we'd be called at the same level with the normal ULDs, making it unpredictable at which time we're called. And it was actually Greg KH which promised the multiple driver binding, but seems that he's not getting around doing this anytime soon. Hmm; maybe I can convince Kay on doing it ... But want we really want to do is _not_ having these 'special' handlers called at any time during bus probing, but having a fixed order like: sdev probing - (optional) device handler attach - bsg attach - SCSI ULD probing We would like to have bsg available before ULD probing, as then we could use the bsg device nodes in general in udev (like calling scsi_id on it). It _might_ be possible to handle these cases with multiple driver binding, but seeing that there's no-one currently working on it I'd like to stick with the current approach. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N�g GF: Markus Rex, HRB 16746 (AG N�g) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
