linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Jones <pjones@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Chandra Seetharaman <sekharan@us.ibm.com>,
	linux-scsi@vger.kernel.org, michaelc@cs.wisc.edu, hare@suse.de
Subject: Re: [PATCH 0/3] scsi_dh: Make scsi device handler modules automatically inserted
Date: Tue, 07 Jul 2009 13:51:15 -0400	[thread overview]
Message-ID: <4A538B13.8050809@redhat.com> (raw)
In-Reply-To: <1246986723.6277.63.camel@mulgrave.site>

On 07/07/2009 01:12 PM, James Bottomley wrote:
> On Fri, 2009-06-26 at 09:56 -0400, Peter Jones wrote:
>> 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.
> 
> Well, you didn't respond to the important one:
> 
> You're seeking to change the binding of these helpers from manual to
> automatic.  This would mean that the modules are loaded in the single
> controller case, for which they may not be wanted and also when some
> multi path tool other than dm-mp is managing the device, in which case
> they may actively interfere with operations.  Your basic contention is
> that you "don't see any concern here".

I think Chandra addressed this in his reply to your previous email: 

[From him]
> This is by design (of SCSI DH). We do want the device to be attached to
> its handler _irrespective_ of whether multipath comes along or not.
> 
> BTW, there is _no_ infrastructure in multipath for handlers. They were
> removed from multipath when scsi dh came along. So, no worries about
> proprietary multipath handlers. Also, multipath _can_ attach a device to
> a different (SCSI) device handler if it finds that the one that is
> already attached is not the right one.

[From you again]
> When I ask what testing you've done for either of these, the studied
> silence eloquently illustrates "none". A policy change like this
> can't be made without being incredibly sure we're not going to screw
> up existing installations.

I'll let Chandra address this, as it is my understanding that he has
hardware and has tested this code with it.

> The second point I made speaks to the technical ugliness of this: what
> you're basically doing is open coding multiple binding for a device
> handler specific case.  If you can persuade me the policy above is
> correct, then technically all this should be done correctly via multiple
> binding in the generic device core ... before this interface nastiness
> you're constructing propagates outwards and becomes part of the user
> ABI.

I'm willing to re-implement the functionality with a different mechanism
if it has your blessing, if you can be specific about what it is you think
would be better.  Obviously I'll hold off on that until we've come to some
agreement about the other aspects.

-- 
        Peter

For some reason it has always seemed to me that the term software 
engineering contains some very optimistic assumptions about the 
nature of reality.

  reply	other threads:[~2009-07-07 17:53 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-27 18:06 [PATCH 0/3] scsi_dh: Make scsi device handler modules automatically inserted Chandra Seetharaman
2009-04-27 18:06 ` [PATCH 1/3] scsi_dh: Add modalias support for SCSI targets Chandra Seetharaman
2009-04-27 18:06 ` [PATCH 2/3] scsi_dh: Change scsi device handler modules to utilize modalias Chandra Seetharaman
2009-04-27 18:06 ` [PATCH 3/3] scsi_dh: Workaround a race condition in module insertion Chandra Seetharaman
2009-06-15 18:29 ` [PATCH 0/3] scsi_dh: Make scsi device handler modules automatically inserted Peter Jones
2009-06-15 23:14   ` Chandra Seetharaman
2009-06-18 22:48   ` James Bottomley
2009-06-19 18:58     ` Peter Jones
2009-06-26 13:56       ` Peter Jones
2009-07-07 17:12         ` James Bottomley
2009-07-07 17:51           ` Peter Jones [this message]
2009-07-07 18:14             ` James Bottomley
2009-07-07 19:36               ` Chandra Seetharaman
2009-07-08 15:53                 ` [PATCH 0/3] scsi_dh: Make scsi device handler modulesautomatically inserted berthiaume_wayne
2009-07-08 18:28                   ` Chandra Seetharaman
2009-07-08 15:58                 ` [PATCH 0/3] scsi_dh: Make scsi device handler modules automatically inserted Christoph Hellwig
2009-07-08 18:21                   ` Chandra Seetharaman
2009-07-08 18:33                   ` Peter Jones
2009-07-08 18:40                     ` Christoph Hellwig
2009-07-08 18:47                       ` Peter Jones
2009-07-15 20:33                     ` Chandra Seetharaman
2009-07-16  1:16                       ` James Bottomley
2009-07-17  1:01                         ` Chandra Seetharaman
2009-07-17  4:19                           ` James Bottomley
2009-07-17 14:14                             ` Peter Jones
2009-07-17 16:45                               ` James Bottomley
2009-07-17 17:13                                 ` Peter Jones
2009-06-19 19:37     ` Chandra Seetharaman
2009-07-06 22:30       ` Chandra Seetharaman
  -- strict thread matches above, loose matches on Subject: below --
2009-03-18  1:36 Chandra Seetharaman
2009-03-18 11:31 ` Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A538B13.8050809@redhat.com \
    --to=pjones@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=sekharan@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).