Re: [PATCH 7/7] scsi_dh: attach to hardware handler from dm-mpath

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2008-05-23 at 13:40 +0200, Hannes Reinecke wrote:
> 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.

That's easily doable provided there's some type of trigger for
registration.  At the moment, it's just a binding free for all since
drivers bind either when they appear (for existing devices) or when the
device appears (for existing drivers).  For the new multiple driver
binding code, I could see a good case for either strictly controlling
the ordering (for binding a new device to existing drivers) or even
making the bindings classification driven.

> 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.

Depends how it's done.  Right at the moment with only a single driver
there's no concept of ordering ... if it's list based, then it would be
in list order, but there's no reason the order can't be dictated by the
bus.

> And it was actually Greg KH which promised the multiple driver binding,
> but seems that he's not getting around doing this anytime soon.

Well, since we have the use case, the rules of open source would tend to
dictate that we have the impetus to do it.  Particularly when there's
tricky questions like binding order to be answered.

> 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.

I think a simple priority based scheme would cope with that.  Say a
single integer in the bus for max priority and then it loops from zero
to max binding all drivers equal to that priority.  We could use 3 (zero
for device handler, one for bsg and 2 for ULD).  We should probably use
1 as the default for everything, giving the ability to bind either
before or after the default (using zero or 2).

James