Re: [PATCH 0/3] scsi_dh: Make scsi device handler modules automatically inserted

[Peter Jones <pjones@redhat.com>]

James, I think Chandra and I have responded to most if not all of your points, 
and would appreciate your thoughts on what we've said.

Peter Jones wrote:
> On 06/18/2009 06:48 PM, James Bottomley wrote:
>> On Mon, 2009-06-15 at 14:29 -0400, Peter Jones wrote:
>>> On 04/27/2009 02:06 PM, Chandra Seetharaman wrote:
>>>> Hello,
>>>>
>>>> Currently, SCSI targets doesn't have modalias support. It wasn't an issue
>>>> until SCSI device handler came along.
>>>>
>>>> We want the SCSI device handler modules to be insmodded automatically
>>>> when the specific SCSI targets are probed and found.
>>>>
>>>> This set of patches adds the modalias support for SCSI targets and
>>>> also makes the relevant changes to SCSI device handler modules to 
>>>> make use of it.
>>>>
>>>> Applies cleanly on 2.6.30-rc3 and is tested on the same.
>>>>
>>>> Please review and consider this for inclusion.
>>>>
>>>> Originally sent on March 17 2009 (http://marc.info/?l=linux-scsi&m=123734001009654&w=2).
>>>>
>>>> Resending after testing on 2.6.30-rc3 and with an ack from Hannes.
>>> Was there ever any followup to this?
>> OK, since I've forgotten where we are, let me summarise what I think the
>> situation is (correct me if I misstate any of the facts):
>>
>> This code adds no functional value to the kernel because dm already
>> autoloads the correct handlers based on the inquiry strings
> 
> I don't agree here.  It adds functional value to the entire system by making the
> loading of device drivers use the same method no matter which kernel subsystem
> the driver is part of.  This is a very tangible benefit in terms of maintainability.
> 
>> The only value it adds is that by overloading the module table with the
>> inquiry strings, mkinitrd pulls in the correct dm handlers for the state
>> the system was in.
> 
> You keep on saying this, and to me it seems very strange.  The patch does no
> "overloading" of vendor strings -- it uses them just like the PCI vendor/device ID or
> USB idVendor/idDevice.  Fundamentally they are the same thing: an identifier to
> tell us what device we're looking at.  There's no overloading here, it's just
> hooking them up to the kernel's generalized mechanism for loading modules based on
> this kind of data.
> 
>> the unaddressed problems are:
>>
>> The kernel now tries to load the dm handler for the device dynamically
>> whether or not the user is actually deploying multi-path (previously dm
>> does this and if it's not loaded, that doesn't happen).  It's entirely
>> unclear whether this would interfere with proprietary multipath handlers
>> or even cause problems in single path systems which were designed that
>> way.
> 
> I just don't see how this is a real concern -- the whole point of the drivers
> which we're autoloading here is to work with specific hardware that's designed to
> work in this fashion.  What's more, if that hardware is being used for single-path,
> and the driver is loaded and it decides to reconfigure to prefer a path that's not
> plugged in, surely that's a bug in the device handler driver, and should be fixed
> there, rather than blocking the auto-loading of such drivers?
> 


-- 
   Peter