Hannes Reinecke wrote:
>> The patch below begins to push the scsi hw handler code down to the
>> scsi
>> layer. I only began to covert dm-emc.c and it only hooks in at the
>> sense
>> decoding in scsi_error.c. I wanted to make sure I was going about the
>> module loading and binding correctly. With a new target bus we could
>> do
>> some driver model stuff instead, but I was not sure if that was
>> appropriate for this?
>>
> Why don't we use scsi_devinfo for this?
I was adding my fields when I noticed this comment:
* Do not add to this list, use the command line or proc interface to add
* to the scsi_dev_info_list. This table will eventually go away.
> We have to have some sort of device table anyway as these handlers are
> far from being generic, so any sense code which triggers action on one
> device might be perfectly ok for others.
When I was looking for the history of that commet, I thought I read that
we are supposed to be moving to some userspace approach that pushes that
info down via some magic interface.
>
> Easiest way would be to have one BLIST flag for each hardware handler
> and merge the respective hardware handler into that target if the
> blacklist entry matches.
>
>> Next up would be to get Jens's cmd type tree and work on the message
>> passing code.
>>
>> And this patch currently does not work since I do not have a Clariion
>> box and I do not know what to match for the {vendor, model} tuple. I
>> think it was something like DCG or DGC and the model had different
>> RAID
>> strings depending on how it was setup and could have some other string
>> if it did not use RAID. If you have a Clariion or you work for EMC and
>> happen to know this info could you pass those strings to me?
>>
> IIRC this is
>
> 'DGC' 'DISK'
> 'DGC' 'RAID 10'
> 'DGC' 'RAID 5'
Thanks.
>
> Hrmph. There is one bit which doesn't quite work out.
> While the hardware handler knows how to handle error codes and how to
> switch
> paths for a specific device, it doesn't know _when_ to switch it.
> I don't think it's a clever idea to switch paths whenever you encounter
> an
> passive path. Seems like you could do a nice ping-pong that way ...
This is what we talked about at the bof. It is what the message passing
cmd type stuff is for. The reason I could not do it yet is that I could
not get Jens's git tree from my hotel.
dm-multipath still decide when to switch like before, but scsi hw
handlers will execute the low level details now.
-
: 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
