Re: [dm-devel] Re: [PATCH RFC] move scsi parts of dm hw handlers to scsi layer

[Mike Christie <michaelc@cs.wisc.edu>]

Hannes Reinecke wrote:
> Am Fr 21.07.2006 13:55 schrieb Mike Christie <michaelc@cs.wisc.edu>:
> 
>> Mike Christie wrote:
>>> 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.
>>>
>> I added this comment at the wrong place. I meant to say I thought we
>> are
>> supposed to be moving away from the kernel devinfo list to some
>> userspace one that gets sent down via the module_param or some new
>> magic
>> interface.
> 
> Or so they claim. I seem to remember some discussion about it; the net
> result was the scsi_devinfo will stay with us for the time being.
> 
> Otherwise you'll end up having to configure your kernel / module during
> startup. With parameters which are static anyway. Can't say I like it.
> And the tricky bit is that these information has to be present prior
> to any initialisation, so you basically have to feed it during
> modprobe time. Not really clever.
> 

He He fun :)

Sticking what we need in devinfo is a lot easier. And I think it makes
sense since the devices info we want to bind with is in there already.
If nobody says anything, I will send the next version of the path with
devinfo integration.