* [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach @ 2011-12-15 21:44 Mike Snitzer 2011-12-20 7:31 ` Hannes Reinecke 0 siblings, 1 reply; 19+ messages in thread From: Mike Snitzer @ 2011-12-15 21:44 UTC (permalink / raw) To: Hannes Reinecke; +Cc: linux-scsi Some scsi_dh modules are known to conflict with with 3rd party multipath drivers (e.g. scsi_dh_emc conflicts with EMC PowerPath). Allow 3rd party multipath drivers to programatically detach a scsi_dh using the scsi_dh_detach() interface rather than require writing 'detach' to /sys/block/sdX/queue/dh_state Signed-off-by: Mike Snitzer <snitzer@redhat.com> --- drivers/scsi/device_handler/scsi_dh.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) [begs the question: why are _any_ of the scsi_dh symbols EXPORT_SYMBOL_GPL? Linux would benefit from more 3rd party use of scsi_dh*. As it stands, Linux is being held back from having better default handling of multipath LUNs purely because 3rd parties may not play nicely with scsi_dh* being attached] diff --git a/drivers/scsi/device_handler/scsi_dh.c b/drivers/scsi/device_handler/scsi_dh.c index 23149b9..a550de1 100644 --- a/drivers/scsi/device_handler/scsi_dh.c +++ b/drivers/scsi/device_handler/scsi_dh.c @@ -578,7 +578,7 @@ void scsi_dh_detach(struct request_queue *q) } put_device(&sdev->sdev_gendev); } -EXPORT_SYMBOL_GPL(scsi_dh_detach); +EXPORT_SYMBOL(scsi_dh_detach); static struct notifier_block scsi_dh_nb = { .notifier_call = scsi_dh_notifier ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach 2011-12-15 21:44 [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach Mike Snitzer @ 2011-12-20 7:31 ` Hannes Reinecke 2012-01-05 15:24 ` Mike Snitzer 2012-04-05 14:47 ` Mike Snitzer 0 siblings, 2 replies; 19+ messages in thread From: Hannes Reinecke @ 2011-12-20 7:31 UTC (permalink / raw) To: Mike Snitzer; +Cc: linux-scsi On 12/15/2011 10:44 PM, Mike Snitzer wrote: > Some scsi_dh modules are known to conflict with with 3rd party multipath > drivers (e.g. scsi_dh_emc conflicts with EMC PowerPath). > > Allow 3rd party multipath drivers to programatically detach a scsi_dh > using the scsi_dh_detach() interface rather than require writing > 'detach' to /sys/block/sdX/queue/dh_state > > Signed-off-by: Mike Snitzer <snitzer@redhat.com> No problem with that. Acked-by: Hannes Reinecke <hare@suse.de> Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach 2011-12-20 7:31 ` Hannes Reinecke @ 2012-01-05 15:24 ` Mike Snitzer 2012-04-05 14:47 ` Mike Snitzer 1 sibling, 0 replies; 19+ messages in thread From: Mike Snitzer @ 2012-01-05 15:24 UTC (permalink / raw) To: Hannes Reinecke; +Cc: linux-scsi On Tue, Dec 20 2011 at 2:31am -0500, Hannes Reinecke <hare@suse.de> wrote: > On 12/15/2011 10:44 PM, Mike Snitzer wrote: > > Some scsi_dh modules are known to conflict with with 3rd party multipath > > drivers (e.g. scsi_dh_emc conflicts with EMC PowerPath). > > > > Allow 3rd party multipath drivers to programatically detach a scsi_dh > > using the scsi_dh_detach() interface rather than require writing > > 'detach' to /sys/block/sdX/queue/dh_state > > > > Signed-off-by: Mike Snitzer <snitzer@redhat.com> > No problem with that. > > Acked-by: Hannes Reinecke <hare@suse.de> Thanks Hannes, So will this change make it into 3.3? In general, I'm not clear on where scsi_dh changes are staged for upstream inclusion. Mike ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach 2011-12-20 7:31 ` Hannes Reinecke 2012-01-05 15:24 ` Mike Snitzer @ 2012-04-05 14:47 ` Mike Snitzer 2012-04-20 14:45 ` [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach Mike Snitzer 1 sibling, 1 reply; 19+ messages in thread From: Mike Snitzer @ 2012-04-05 14:47 UTC (permalink / raw) To: James.Bottomley; +Cc: linux-scsi, Hannes Reinecke On Tue, Dec 20 2011 at 2:31am -0500, Hannes Reinecke <hare@suse.de> wrote: > On 12/15/2011 10:44 PM, Mike Snitzer wrote: > > Some scsi_dh modules are known to conflict with with 3rd party multipath > > drivers (e.g. scsi_dh_emc conflicts with EMC PowerPath). > > > > Allow 3rd party multipath drivers to programatically detach a scsi_dh > > using the scsi_dh_detach() interface rather than require writing > > 'detach' to /sys/block/sdX/queue/dh_state > > > > Signed-off-by: Mike Snitzer <snitzer@redhat.com> > No problem with that. > > Acked-by: Hannes Reinecke <hare@suse.de> Hi James, Can we get this patch staged for 3.5? Thanks, Mike ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach 2012-04-05 14:47 ` Mike Snitzer @ 2012-04-20 14:45 ` Mike Snitzer 2012-04-20 15:17 ` James Bottomley 2012-04-20 17:34 ` [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL Mike Snitzer 0 siblings, 2 replies; 19+ messages in thread From: Mike Snitzer @ 2012-04-20 14:45 UTC (permalink / raw) To: James.Bottomley Cc: linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel Allow 3rd party multipath drivers to programatically detach a scsi_dh using the scsi_dh_detach() interface. This is as improvement over requiring them to write 'detach' to /sys/block/sdX/queue/dh_state End result is both Linux and 3rd party multipath drivers can coexist without compromising Linux's default handling of multipath LUNs. Linux has suffered from races associated with attaching a scsi_dh to a device too late (after an HBA driver has started the SCSI device scan). Attaching a scsi_dh too late results in default sense handling that does not silently fail IO to passive paths, which creates excessive delays and IO errors during normal boot on a system with hundreds of LUNs. To fix this the appropriate scsi_dh must be attached before the HBA driver(s) are even loaded. But some scsi_dh are known to conflict with 3rd party multipath drivers (e.g. both scsi_dh_alua and scsi_dh_emc conflict with EMC PowerPath). This patch allows 3rd party drivers to resolve the conflict by detaching an attached scsi_dh. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Acked-by: Hannes Reinecke <hare@suse.de> Cc: Chandra Seetharaman <sekharan@us.ibm.com> --- drivers/scsi/device_handler/scsi_dh.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/device_handler/scsi_dh.c b/drivers/scsi/device_handler/scsi_dh.c index 23149b9..a550de1 100644 --- a/drivers/scsi/device_handler/scsi_dh.c +++ b/drivers/scsi/device_handler/scsi_dh.c @@ -578,7 +578,7 @@ void scsi_dh_detach(struct request_queue *q) } put_device(&sdev->sdev_gendev); } -EXPORT_SYMBOL_GPL(scsi_dh_detach); +EXPORT_SYMBOL(scsi_dh_detach); static struct notifier_block scsi_dh_nb = { .notifier_call = scsi_dh_notifier ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach 2012-04-20 14:45 ` [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach Mike Snitzer @ 2012-04-20 15:17 ` James Bottomley 2012-04-20 15:46 ` Mike Snitzer 2012-04-20 15:49 ` Chandra Seetharaman 2012-04-20 17:34 ` [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL Mike Snitzer 1 sibling, 2 replies; 19+ messages in thread From: James Bottomley @ 2012-04-20 15:17 UTC (permalink / raw) To: Mike Snitzer Cc: linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel On Fri, 2012-04-20 at 10:45 -0400, Mike Snitzer wrote: > Allow 3rd party multipath drivers to programatically detach a scsi_dh > using the scsi_dh_detach() interface. This is as improvement over > requiring them to write 'detach' to /sys/block/sdX/queue/dh_state > > End result is both Linux and 3rd party multipath drivers can coexist > without compromising Linux's default handling of multipath LUNs. > > Linux has suffered from races associated with attaching a scsi_dh to a > device too late (after an HBA driver has started the SCSI device scan). > Attaching a scsi_dh too late results in default sense handling that does > not silently fail IO to passive paths, which creates excessive delays > and IO errors during normal boot on a system with hundreds of LUNs. > > To fix this the appropriate scsi_dh must be attached before the HBA > driver(s) are even loaded. But some scsi_dh are known to conflict with > 3rd party multipath drivers (e.g. both scsi_dh_alua and scsi_dh_emc > conflict with EMC PowerPath). This patch allows 3rd party drivers to > resolve the conflict by detaching an attached scsi_dh. This changelog is a bit misleading, isn't it? The basic problem is that binary only third party drivers can't use the scsi_dh_detach callback because it's GPL only. The only module I know which suffers this problem is powerpath, is that right? So this patch actually relaxes our GPL only policy to allow powerpath to detach correctly. I really don't like the characterisation in the current proposed changelog of this being a "third party" problem because quite a few third party modules actually provide source and are thus GPL compliant. The whole point of GPL only symbols is to make life difficult for binary modules, so I could just say this might be indicative of the success of that policy. On the other hand, I'm not going to be religious about this. If you get the ack of the dh handler maintainer (Chandra Seetharaman) I'll apply this policy relaxation with a proper changelog that says what we're doing (allowing powerpath to bind to the symbol). James ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach 2012-04-20 15:17 ` James Bottomley @ 2012-04-20 15:46 ` Mike Snitzer 2012-04-20 15:49 ` Chandra Seetharaman 1 sibling, 0 replies; 19+ messages in thread From: Mike Snitzer @ 2012-04-20 15:46 UTC (permalink / raw) To: James Bottomley Cc: linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel On Fri, Apr 20 2012 at 11:17am -0400, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > On Fri, 2012-04-20 at 10:45 -0400, Mike Snitzer wrote: > > Allow 3rd party multipath drivers to programatically detach a scsi_dh > > using the scsi_dh_detach() interface. This is as improvement over > > requiring them to write 'detach' to /sys/block/sdX/queue/dh_state > > > > End result is both Linux and 3rd party multipath drivers can coexist > > without compromising Linux's default handling of multipath LUNs. > > > > Linux has suffered from races associated with attaching a scsi_dh to a > > device too late (after an HBA driver has started the SCSI device scan). > > Attaching a scsi_dh too late results in default sense handling that does > > not silently fail IO to passive paths, which creates excessive delays > > and IO errors during normal boot on a system with hundreds of LUNs. > > > > To fix this the appropriate scsi_dh must be attached before the HBA > > driver(s) are even loaded. But some scsi_dh are known to conflict with > > 3rd party multipath drivers (e.g. both scsi_dh_alua and scsi_dh_emc > > conflict with EMC PowerPath). This patch allows 3rd party drivers to > > resolve the conflict by detaching an attached scsi_dh. > > This changelog is a bit misleading, isn't it? > > The basic problem is that binary only third party drivers can't use the > scsi_dh_detach callback because it's GPL only. The only module I know > which suffers this problem is powerpath, is that right? > > So this patch actually relaxes our GPL only policy to allow powerpath to > detach correctly. I really don't like the characterisation in the > current proposed changelog of this being a "third party" problem because > quite a few third party modules actually provide source and are thus GPL > compliant. > > The whole point of GPL only symbols is to make life difficult for binary > modules, so I could just say this might be indicative of the success of > that policy. On the other hand, I'm not going to be religious about > this. If you get the ack of the dh handler maintainer (Chandra > Seetharaman) I'll apply this policy relaxation with a proper changelog > that says what we're doing (allowing powerpath to bind to the symbol). Would s/3rd party/proprietary/ be OK? There are other proprietary multipath drivers (e.g. veritas DMP). So the issue is theoretically more generic than powerpath. But in practice powerpath is the most widely deployed conflict that motivated this change. Though I could easily imagine our policy to treat Powerpath with kid gloves has made us unaware of the potential for other proprietary multipath drivers having the same conflict with scsi_dh. FYI, I'm looking to have RHEL7 blaze trails and shake things up by forcing proprietary multipath drivers to detach scsi_dh (EMC is aware of this). Mike ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach 2012-04-20 15:17 ` James Bottomley 2012-04-20 15:46 ` Mike Snitzer @ 2012-04-20 15:49 ` Chandra Seetharaman 1 sibling, 0 replies; 19+ messages in thread From: Chandra Seetharaman @ 2012-04-20 15:49 UTC (permalink / raw) To: Mike Snitzer, James Bottomley; +Cc: linux-scsi, Hannes Reinecke, linux-kernel Mike, First off, sorry for not responding on this earlier. When I saw the original patch, I was thinking it is a generic policy issue, and James would be a better person to make decision on this, and forgot about it. Now only realized that James was waiting on me. I am not very religious either, and agree with James on changing the Changelog. With that change, Acked-by: Chandra Seetharaman <sekharan@us.ibm.com> Regards, Chandra On Fri, 2012-04-20 at 19:17 +0400, James Bottomley wrote: > On Fri, 2012-04-20 at 10:45 -0400, Mike Snitzer wrote: > > Allow 3rd party multipath drivers to programatically detach a scsi_dh > > using the scsi_dh_detach() interface. This is as improvement over > > requiring them to write 'detach' to /sys/block/sdX/queue/dh_state > > > > End result is both Linux and 3rd party multipath drivers can coexist > > without compromising Linux's default handling of multipath LUNs. > > > > Linux has suffered from races associated with attaching a scsi_dh to a > > device too late (after an HBA driver has started the SCSI device scan). > > Attaching a scsi_dh too late results in default sense handling that does > > not silently fail IO to passive paths, which creates excessive delays > > and IO errors during normal boot on a system with hundreds of LUNs. > > > > To fix this the appropriate scsi_dh must be attached before the HBA > > driver(s) are even loaded. But some scsi_dh are known to conflict with > > 3rd party multipath drivers (e.g. both scsi_dh_alua and scsi_dh_emc > > conflict with EMC PowerPath). This patch allows 3rd party drivers to > > resolve the conflict by detaching an attached scsi_dh. > > This changelog is a bit misleading, isn't it? > > The basic problem is that binary only third party drivers can't use the > scsi_dh_detach callback because it's GPL only. The only module I know > which suffers this problem is powerpath, is that right? > > So this patch actually relaxes our GPL only policy to allow powerpath to > detach correctly. I really don't like the characterisation in the > current proposed changelog of this being a "third party" problem because > quite a few third party modules actually provide source and are thus GPL > compliant. > > The whole point of GPL only symbols is to make life difficult for binary > modules, so I could just say this might be indicative of the success of > that policy. On the other hand, I'm not going to be religious about > this. If you get the ack of the dh handler maintainer (Chandra > Seetharaman) I'll apply this policy relaxation with a proper changelog > that says what we're doing (allowing powerpath to bind to the symbol). > > James > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-20 14:45 ` [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach Mike Snitzer 2012-04-20 15:17 ` James Bottomley @ 2012-04-20 17:34 ` Mike Snitzer 2012-04-20 20:41 ` Alan Cox 1 sibling, 1 reply; 19+ messages in thread From: Mike Snitzer @ 2012-04-20 17:34 UTC (permalink / raw) To: James.Bottomley Cc: linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel Allow a proprietary non-GPL multipath driver, like EMC PowerPath, to detach a scsi_dh using scsi_dh_detach. This is an improvement over requiring them to write 'detach' to /sys/block/sdX/queue/dh_state End result is Linux and PowerPath can coexist without compromising Linux's default handling of multipath LUNs. Linux has suffered from the race where a scsi_dh is not available to be attached to a SCSI device until too late (after an HBA driver has started the SCSI device scan that may attach a scsi_dh). Attaching a scsi_dh too late results in default sense handling that does not silently end IO to passive paths, which creates excessive delays and IO errors during normal boot of a system with hundreds of LUNs. To fix this the appropriate scsi_dh must be available to be attached before an HBA driver's SCSI device scan. But once attached, both scsi_dh_alua and scsi_dh_emc are known to conflict with PowerPath -- allowing PowerPath to use scsi_dh_detach resolves such conflicts. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Acked-by: Hannes Reinecke <hare@suse.de> Acked-by: Chandra Seetharaman <sekharan@us.ibm.com> --- drivers/scsi/device_handler/scsi_dh.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) v2: header tweaks, added Chandra's Acked-by p.s. James, if you still think I'm too indirect or long-winded please feel free to change the header accordingly. Thanks! diff --git a/drivers/scsi/device_handler/scsi_dh.c b/drivers/scsi/device_handler/scsi_dh.c index 23149b9..a550de1 100644 --- a/drivers/scsi/device_handler/scsi_dh.c +++ b/drivers/scsi/device_handler/scsi_dh.c @@ -578,7 +578,7 @@ void scsi_dh_detach(struct request_queue *q) } put_device(&sdev->sdev_gendev); } -EXPORT_SYMBOL_GPL(scsi_dh_detach); +EXPORT_SYMBOL(scsi_dh_detach); static struct notifier_block scsi_dh_nb = { .notifier_call = scsi_dh_notifier ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-20 17:34 ` [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL Mike Snitzer @ 2012-04-20 20:41 ` Alan Cox 2012-04-20 21:58 ` Mike Snitzer 0 siblings, 1 reply; 19+ messages in thread From: Alan Cox @ 2012-04-20 20:41 UTC (permalink / raw) To: Mike Snitzer Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel On Fri, 20 Apr 2012 13:34:05 -0400 Mike Snitzer <snitzer@redhat.com> wrote: > Allow a proprietary non-GPL multipath driver, like EMC PowerPath, to > detach a scsi_dh using scsi_dh_detach. That I doubt somehow. The GPL covers *all* derivative works. EXPORT_SYMBOL doesn't magically make code non-derivative. If you need to modify the kernel to make your driver work *and* you want to claim it is not derivative then I hope there are good lawyers involved 8-) The kernel is GPL, all derived works of a GPL codebase are required to be GPL. There is no magic rule about modules. I've stated that repeatedly for anything containing a line of code I own. GregKH has made it very clear for his code, and so it goes on. > End result is Linux and PowerPath can coexist without compromising > Linux's default handling of multipath LUNs. So your specific purpose seems to me to be to enable a third party piece of non-free code to hook into a piece of GPL code that it needs (which to me implies it is derivative if it does). There is an offence of "conspiracy to commit copyright infringement" so merely grinning and saying its for a third party doesn't let your company off the hook either. You should probably forward it to your legal teams before taking any other action. Deleting it won't make it go away. It's up to them to decide if they think they can argue properly that the work is not derivative. I shall be most intrigued to see anyone make that argument, but hey I'm not a lawyer. I'm dying to see anyone make the moral argument for it too. Alan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-20 20:41 ` Alan Cox @ 2012-04-20 21:58 ` Mike Snitzer 2012-04-20 22:20 ` Alan Cox 0 siblings, 1 reply; 19+ messages in thread From: Mike Snitzer @ 2012-04-20 21:58 UTC (permalink / raw) To: Alan Cox Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel On Fri, Apr 20 2012 at 4:41pm -0400, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > On Fri, 20 Apr 2012 13:34:05 -0400 > Mike Snitzer <snitzer@redhat.com> wrote: > > > Allow a proprietary non-GPL multipath driver, like EMC PowerPath, to > > detach a scsi_dh using scsi_dh_detach. > > That I doubt somehow. The GPL covers *all* derivative works. > EXPORT_SYMBOL doesn't magically make code non-derivative. If you need to > modify the kernel to make your driver work *and* you want to claim it is > not derivative then I hope there are good lawyers involved 8-) Um... now I see that cc'ing LKML was a mistake: GPL zealots reading into this _way_ more than is warranted... awesome. > The kernel is GPL, all derived works of a GPL codebase are required to be > GPL. There is no magic rule about modules. I've stated that repeatedly > for anything containing a line of code I own. GregKH has made it very > clear for his code, and so it goes on. This isn't about adding Linux functionality to a proprietary driver. It is about the fact that: 1) Linux's scsi_dh* adds additional SCSI sense processing that conflicts with processing that a long established competing proprietary driver also does (and did long before scsi_dh* was introduced). 2) If Linux is masking SCSI sense that Powerpath needs to see in order to function then they need a way to shut off that conflicting functionality in Linux. What they have enjoyed until now is that Linux has treated them with kid gloves -- by not always attaching scsi_dh to each SCSI device during SCSI device scan. Well it is now time to put Linux (and Linux multipathing) first! But doing so while exposing an interface that allows Linux to not have to make compromises about how good it can be. > > End result is Linux and PowerPath can coexist without compromising > > Linux's default handling of multipath LUNs. > > So your specific purpose seems to me to be to enable a third party piece > of non-free code to hook into a piece of GPL code that it needs (which to > me implies it is derivative if it does). There is an offence of > "conspiracy to commit copyright infringement" so merely grinning and > saying its for a third party doesn't let your company off the hook either. > > You should probably forward it to your legal teams before taking any > other action. Deleting it won't make it go away. It's up to them to > decide if they think they can argue properly that the work is not > derivative. I shall be most intrigued to see anyone make that argument, > but hey I'm not a lawyer. > > I'm dying to see anyone make the moral argument for it too. I think you're blinded by some innate violent pain reaction to seeing s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/ As I said in the header, Linux's ability to properly support scanning LUNs with multiple paths has been fragile for _years_ purely because we never had the balls to always attach the scsi_dh which enables Linux to work well. We didn't because of fear that we'd break PowerPath. As a result, Linux has suffered (in the form of reduced functionality). Now your arguing that the because scsi_dh_detach() will become EXPORT_SYMBOL it somehow makes PowerPath a derived work if they were to use it?!? -- even though they clearly cannot use scsi_dh* in their non-GPL driver because all the other scsi_dh* interfaces (like scsi_dh_attach!) are _GPL? The two other people (scsi_dh maintainers) that Acked-by this change work for companies other than EMC. James is the SCSI maintainer and understands what is going on here. Like me, they are domain experts. What are you? You're not a lawyer, you're also clearly uninformed. So why even weigh in on something if you cannot understand what the hell is being proposed? You're being a troll... sad really. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-20 21:58 ` Mike Snitzer @ 2012-04-20 22:20 ` Alan Cox 2012-04-20 22:58 ` Mike Snitzer 0 siblings, 1 reply; 19+ messages in thread From: Alan Cox @ 2012-04-20 22:20 UTC (permalink / raw) To: Mike Snitzer Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel > > The kernel is GPL, all derived works of a GPL codebase are required to be > > GPL. There is no magic rule about modules. I've stated that repeatedly > > for anything containing a line of code I own. GregKH has made it very > > clear for his code, and so it goes on. > > This isn't about adding Linux functionality to a proprietary driver. Let me quote back your previous message "Allow a proprietary non-GPL multipath driver, like EMC PowerPath, to detach a scsi_dh using scsi_dh_detach." what part of that isn't about proprietary drivers. > If Linux is masking SCSI sense that Powerpath needs to see in order to > function then they need a way to shut off that conflicting functionality > in Linux. What they have enjoyed until now is that Linux has treated > them with kid gloves -- by not always attaching scsi_dh to each SCSI > device during SCSI device scan. They can submit the powerpath code to the GPL kernel and it can get dealt with nicely. > > I'm dying to see anyone make the moral argument for it too. > > I think you're blinded by some innate violent pain reaction to seeing > s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/ No. I'm just reminding you and Red Hat that the kernel is subject to the GPLv2 licence and that adding/removing _GPL from a symbol doesn't magically allow you to use proprietary modules as you claim. > As I said in the header, Linux's ability to properly support scanning > LUNs with multiple paths has been fragile for _years_ purely because we > never had the balls to always attach the scsi_dh which enables Linux to > work well. We didn't because of fear that we'd break PowerPath. Thats unfortunate. You mean your company has been intentionally leaving the Linux kernel poorer for the sake of dubious proprietary code ? You might want to stop digging, or at least use a spade not an excavator. > As a result, Linux has suffered (in the form of reduced functionality). > Now your arguing that the because scsi_dh_detach() will become > EXPORT_SYMBOL it somehow makes PowerPath a derived work if they were to I suspect it is already a derived work, but right now that's their problem. You are making it yours as well. > The two other people (scsi_dh maintainers) that Acked-by this change > work for companies other than EMC. James is the SCSI maintainer and > understands what is going on here. Like me, they are domain experts. > > What are you? I'm a rights holder. Domain expertise isn't relevant here. The code I provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the kernel be modified to match it) cannot call it. I'm recommended by my lawyer to always remind people of this when such a claim is made. It ensures that triple damages for wilful infringement will apply unless the other party can show it reviewed the situation carefully and its appropriately qualified legal staff reached a different conclusion. Obviously what action you take is up to Red Hat's legal (and PR) folks. However I'd suggest you talk to them first, as per Red Hat training unless that has changed.. Alan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-20 22:20 ` Alan Cox @ 2012-04-20 22:58 ` Mike Snitzer 2012-04-20 23:14 ` Alan Cox 0 siblings, 1 reply; 19+ messages in thread From: Mike Snitzer @ 2012-04-20 22:58 UTC (permalink / raw) To: Alan Cox Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel On Fri, Apr 20 2012 at 6:20pm -0400, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > > The kernel is GPL, all derived works of a GPL codebase are required to be > > > GPL. There is no magic rule about modules. I've stated that repeatedly > > > for anything containing a line of code I own. GregKH has made it very > > > clear for his code, and so it goes on. > > > > This isn't about adding Linux functionality to a proprietary driver. > > Let me quote back your previous message > > "Allow a proprietary non-GPL multipath driver, like EMC > PowerPath, to detach a scsi_dh using scsi_dh_detach." > > what part of that isn't about proprietary drivers. Sure Alan, seize on "proprietary" and "EXPORT_SYMBOL_GPL".. and gloss right over the fact that what is being proposed is reasonable. Any multipath driver should be able to detach a scsi_dh module. As is evidenced by the fact that they can already make use of sysfs to do so. Relaxing the scsi_dh_detach interface makes it easier for a long standing proprietary driver to get out of Linux's way. But yeah, I'm sure you'll gloss over that too. > > If Linux is masking SCSI sense that Powerpath needs to see in order to > > function then they need a way to shut off that conflicting functionality > > in Linux. What they have enjoyed until now is that Linux has treated > > them with kid gloves -- by not always attaching scsi_dh to each SCSI > > device during SCSI device scan. > > They can submit the powerpath code to the GPL kernel and it can get dealt > with nicely. > > > > I'm dying to see anyone make the moral argument for it too. > > > > I think you're blinded by some innate violent pain reaction to seeing > > s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/ > > No. I'm just reminding you and Red Hat that the kernel is subject to the > GPLv2 licence and that adding/removing _GPL from a symbol doesn't > magically allow you to use proprietary modules as you claim. > > > As I said in the header, Linux's ability to properly support scanning > > LUNs with multiple paths has been fragile for _years_ purely because we > > never had the balls to always attach the scsi_dh which enables Linux to > > work well. We didn't because of fear that we'd break PowerPath. > > Thats unfortunate. You mean your company has been intentionally > leaving the Linux kernel poorer for the sake of dubious proprietary > code ? > > You might want to stop digging, or at least use a spade not an excavator. _Upstream_ has kept it that way because we've been concerned about breaking PowerPath in enterprises where Linux is deployed. Upstream has been good citizens to the fault of Linux. Please stop being a drama queen and stop putting words in my mouth. > > As a result, Linux has suffered (in the form of reduced functionality). > > Now your arguing that the because scsi_dh_detach() will become > > EXPORT_SYMBOL it somehow makes PowerPath a derived work if they were to > > I suspect it is already a derived work, but right now that's their > problem. You are making it yours as well. > > > The two other people (scsi_dh maintainers) that Acked-by this change > > work for companies other than EMC. James is the SCSI maintainer and > > understands what is going on here. Like me, they are domain experts. > > > > What are you? > > I'm a rights holder. Domain expertise isn't relevant here. The code I > provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL > or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the > kernel be modified to match it) cannot call it. Remind me again when you ever developed anything to do with scsi_dh? To be clear: PowerPath doesn't _need_ this. Not even close. Linux is improved by not having to walk on egg shells that attaching a helpful linux-only layer in kernel will somehow screw up some 3rd party software that a customer values. You still don't get it... yet you'll saber rattle behind generic GPL lawyer-up nonsense. It is sad that you didn't even read the important technical aspects of my previous reply that prove you're being a troll. I implore you to defer to the domain experts and refrain from continued late Friday night geek melo-drama. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-20 22:58 ` Mike Snitzer @ 2012-04-20 23:14 ` Alan Cox 2012-04-20 23:34 ` Mike Snitzer 2012-04-22 22:13 ` Mike Snitzer 0 siblings, 2 replies; 19+ messages in thread From: Alan Cox @ 2012-04-20 23:14 UTC (permalink / raw) To: Mike Snitzer Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel > Sure Alan, seize on "proprietary" and "EXPORT_SYMBOL_GPL".. and gloss > right over the fact that what is being proposed is reasonable. I suggest you read the licence document. > Any multipath driver should be able to detach a scsi_dh module. As is > evidenced by the fact that they can already make use of sysfs to do so. They can call the _GPL version if they are GPL, so there is no problem. > Relaxing the scsi_dh_detach interface makes it easier for a long > standing proprietary driver to get out of Linux's way. So we are back to this being for a proprietary driver trying to link with GPL code. > _Upstream_ has kept it that way because we've been concerned about > breaking PowerPath in enterprises where Linux is deployed. Upstream has > been good citizens to the fault of Linux. Not from where I am standing. It sounds like upstream has suffered for the benefit of a dubious proprietary module. > > I'm a rights holder. Domain expertise isn't relevant here. The code I > > provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL > > or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the > > kernel be modified to match it) cannot call it. > > Remind me again when you ever developed anything to do with scsi_dh? It's part of the same kernel. It's GPL code. You can take your own code and relicense it to be non GPL if you wish, but not mine nor Greg's nor anyone elses. > To be clear: PowerPath doesn't _need_ this. Not even close. Then we don't need to apply it ? Thank you for clarifying that. > Linux is improved by not having to walk on egg shells that attaching a > helpful linux-only layer in kernel will somehow screw up some 3rd party > software that a customer values. That's a problem for Red Hat. Don't dump it on upstream. If the kernel would work better with scsi_dh always attached we should always attach it. It's the problem of the out of tree people how they cope. They'll figure something out. And you still have the same confusion There is no "Linux only" magic in _GPL. Any derivative work of a GPL work must be distributed under the GPL. > You still don't get it... yet you'll saber rattle behind generic GPL > lawyer-up nonsense. This has gone far enough but it seems your management has already jumped on it. Not my preferred way of handling such matters but Red Hat legal and PR need to rein you in before you cause some serious damage. Alan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-20 23:14 ` Alan Cox @ 2012-04-20 23:34 ` Mike Snitzer 2012-04-22 22:13 ` Mike Snitzer 1 sibling, 0 replies; 19+ messages in thread From: Mike Snitzer @ 2012-04-20 23:34 UTC (permalink / raw) To: Alan Cox Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel On Fri, Apr 20 2012 at 7:14pm -0400, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > Sure Alan, seize on "proprietary" and "EXPORT_SYMBOL_GPL".. and gloss > > right over the fact that what is being proposed is reasonable. > > I suggest you read the licence document. > > > Any multipath driver should be able to detach a scsi_dh module. As is > > evidenced by the fact that they can already make use of sysfs to do so. > > They can call the _GPL version if they are GPL, so there is no problem. > > > Relaxing the scsi_dh_detach interface makes it easier for a long > > standing proprietary driver to get out of Linux's way. > > So we are back to this being for a proprietary driver trying to link with > GPL code. > > > _Upstream_ has kept it that way because we've been concerned about > > breaking PowerPath in enterprises where Linux is deployed. Upstream has > > been good citizens to the fault of Linux. > > Not from where I am standing. It sounds like upstream has suffered for > the benefit of a dubious proprietary module. > > > > I'm a rights holder. Domain expertise isn't relevant here. The code I > > > provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL > > > or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the > > > kernel be modified to match it) cannot call it. > > > > Remind me again when you ever developed anything to do with scsi_dh? > > It's part of the same kernel. It's GPL code. You can take your own code > and relicense it to be non GPL if you wish, but not mine nor Greg's nor > anyone elses. The scsi_dh maintainer (Chandra) acked the change. Hannes, the author of scsi_dh_attach, acked the change. You don't have a leg to stand on. Time for you to face that fact. > > To be clear: PowerPath doesn't _need_ this. Not even close. > > Then we don't need to apply it ? Thank you for clarifying that. > > > Linux is improved by not having to walk on egg shells that attaching a > > helpful linux-only layer in kernel will somehow screw up some 3rd party > > software that a customer values. > > That's a problem for Red Hat. Don't dump it on upstream. If the kernel > would work better with scsi_dh always attached we should always attach > it. It's the problem of the out of tree people how they cope. They'll > figure something out. > > And you still have the same confusion > > There is no "Linux only" magic in _GPL. Any derivative work of a GPL work > must be distributed under the GPL. You asserting something doesn't make it so. > > You still don't get it... yet you'll saber rattle behind generic GPL > > lawyer-up nonsense. > > This has gone far enough but it seems your management has already jumped > on it. Not my preferred way of handling such matters but Red Hat legal and > PR need to rein you in before you cause some serious damage. What the hell are you talking about? Please stop the insanity. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-20 23:14 ` Alan Cox 2012-04-20 23:34 ` Mike Snitzer @ 2012-04-22 22:13 ` Mike Snitzer 2012-04-22 22:34 ` Alan Cox 1 sibling, 1 reply; 19+ messages in thread From: Mike Snitzer @ 2012-04-22 22:13 UTC (permalink / raw) To: Alan Cox Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel On Fri, Apr 20 2012 at 7:14pm -0400, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > There is no "Linux only" magic in _GPL. Any derivative work of a GPL work > must be distributed under the GPL. The author and maintainers of the scsi_dh code agreed that relaxing scsi_dh_detach's export was fine and they acked the change. Their rights are important too. And I understand what you're saying about you and others being rights holders that have a say. But communication has broken down because you've been unwilling to concede that those who have acked this relaxation _know_ that what scsi_dh provides is _not_ unique functionality to Linux or Linux SCSI multipathing. Allowing a proprietary driver to use scsi_dh_detach to unload scsh_dh*'s associated additional SCSI sense and error processing doesn't implicitly mean said driver is using derived work to achieve it's comparable processing. It simply means their offering reasonably conflicts with what Linux is providing: All SCSI multipathing drivers are expected to interpret and react to SCSI sense information. Doing so is not an innovation unique to Linux. Because it is not unique it collides with a long established proprietary driver's offering. > > You still don't get it... yet you'll saber rattle behind generic GPL > > lawyer-up nonsense. > > This has gone far enough but it seems your management has already jumped > on it. Not my preferred way of handling such matters but Red Hat legal and > PR need to rein you in before you cause some serious damage. Yes, secretly switching channels to google+ and lobbing questions about Red Hat's commitment to free software at one of Red Hat's OSS community leaders probably isn't the preferred way to handle such things. But seeing a s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/ change clearly does trigger a negative reaction for some (and that really doesn't make them "zealots"). However the validity of making that change should not be so easily stifled with rhetorical GPL violation theory or legal threat. I don't respond well to threats but could have certainly used more tact in my original responses to you. You capture the hearts and minds of many Linux and GPL stakeholders and are well respected -- and believe it or not I'm not some naive or reckless individual. I am a professional Linux developer who works for the most respected name in Open Source development. And I now do _not_ have concerns of legal issues associated with this change. I genuinely do appreciate your concern though. You view this change as detrimental to Linux and think it could theoretically be enabling proprietary use of derived work. Reasonable initial concern but this change does not do that for the intended use -- as hard as it may be to believe it actually benefits Linux multipathing. And as I said on google+: "I've been very pragmatic with my reasoning behind this change and followed the established process of getting author and maintainer buy-off. None of us are out to hurt Linux." With that said, I'm leaving the decision of whether or not to relax scsi_dh_detach's export in the very capable hands of James Bottomley. I'll be fine with whatever James decides but do hope that this outcry will not serve to establish precedent that ties our hands in the future when comparable decisions need to be made about the improvement of Linux's interfaces and overall function. Regards, Mike ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-22 22:13 ` Mike Snitzer @ 2012-04-22 22:34 ` Alan Cox 2012-04-22 23:01 ` Mike Snitzer 0 siblings, 1 reply; 19+ messages in thread From: Alan Cox @ 2012-04-22 22:34 UTC (permalink / raw) To: Mike Snitzer Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel > The author and maintainers of the scsi_dh code agreed that relaxing > scsi_dh_detach's export was fine and they acked the change. Their > rights are important too. They can only grant rights beyond the GPL providing they remove everyone elses code. But that isn't the big issue. I wish you'd go talk to your legal team, then you might understand the real problem here. But you won't, so I'll hopefully be talking to them tomorrow. > And I understand what you're saying about you and others being rights > holders that have a say. But communication has broken down because > you've been unwilling to concede that those who have acked this > relaxation _know_ that what scsi_dh provides is _not_ unique > functionality to Linux or Linux SCSI multipathing. "Unwilling to concede". There is nothing to concede. The GPL spells out the rules. Also if you'd have talked to Red Hat legal you'd have understood there are other issues here. > Allowing a proprietary driver to use scsi_dh_detach to unload scsh_dh*'s > associated additional SCSI sense and error processing doesn't implicitly > mean said driver is using derived work to achieve it's comparable > processing. It simply means their offering reasonably conflicts with > what Linux is providing: Can I suggest you don't make legal statements from a Red Hat address without talking to your legal team. It's not a good idea and tends to get people into trouble. > All SCSI multipathing drivers are expected to interpret and react to > SCSI sense information. Doing so is not an innovation unique to Linux. > Because it is not unique it collides with a long established proprietary > driver's offering. That's their problem. They chose not to play ball, and they are going to have to run after us and sort their own mess out. They'll cope as they've had a lot of practice at it. > Yes, secretly switching channels to google+ and lobbing questions about > Red Hat's commitment to free software at one of Red Hat's OSS community > leaders probably isn't the preferred way to handle such things. I didn't do anything secret. How is posting publically "secret". Also I made very sure the people who needed to see it in Red Hat did, so they can do something about it and rein you in. It's had the right effect and it means the right folks in Red Hat can look at the issue itself. > You capture the hearts and minds of many Linux and GPL stakeholders and > are well respected -- and believe it or not I'm not some naive or > reckless individual. I am a professional Linux developer who works for > the most respected name in Open Source development. I spent ten years at Red Hat, I'd like them to keep that reputation which is one of the reasons this bothers me a lot. The other being the legal issues. > And I now do _not_ have concerns of legal issues associated with this > change. I genuinely do appreciate your concern though. Well that's for Red Hat management and legal to determine, unless you are also a practicing IP lawyer as well ? > With that said, I'm leaving the decision of whether or not to relax > scsi_dh_detach's export in the very capable hands of James Bottomley. > > I'll be fine with whatever James decides but do hope that this outcry > will not serve to establish precedent that ties our hands in the future > when comparable decisions need to be made about the improvement of > Linux's interfaces and overall function. This isn't tying your hands. There are two things which tie your hands here - the GPL (intentionally) and certain properties of US law - which I'll discuss with the appropriate Red Hat people in an appropriate forum. You clearly are not that appropriate person. Perhaps after that they can explain to you in the proper manner internally - Why legal matters should be referred to lawyers for checking. - Why your patch may raise a particularly nasty potential problem if it were merged Alan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-22 22:34 ` Alan Cox @ 2012-04-22 23:01 ` Mike Snitzer 2012-04-22 23:13 ` Alan Cox 0 siblings, 1 reply; 19+ messages in thread From: Mike Snitzer @ 2012-04-22 23:01 UTC (permalink / raw) To: Alan Cox Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel Funny thing happens when you assume too much... Anyway, your no compromises approach is admirable but it doesn't erase the fact that all proprietary Linux drivers use EXPORT_SYMBOL code. So what you're really saying is no proprietary drivers are allowed to be loaded into a Linux kernel. Nice that you've made this scsi_dh_detach change the frontline of a battle that has already been lost years ago. Thanks for your time, Mike ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL 2012-04-22 23:01 ` Mike Snitzer @ 2012-04-22 23:13 ` Alan Cox 0 siblings, 0 replies; 19+ messages in thread From: Alan Cox @ 2012-04-22 23:13 UTC (permalink / raw) To: Mike Snitzer Cc: James.Bottomley, linux-scsi, Hannes Reinecke, Chandra Seetharaman, linux-kernel > Anyway, your no compromises approach is admirable but it doesn't erase > the fact that all proprietary Linux drivers use EXPORT_SYMBOL code. People still steal from shops. It doesn't mean we should abolish the idea of theft. > So what you're really saying is no proprietary drivers are allowed to be > loaded into a Linux kernel. The GPL defines the boundary. Whether it is possible for a work to be non-derivative and a kernel module is a matter for the lawyers to debate. If it is derivative however I don't think there is quite so much doubt. Linus wrote the following |>"On Wed, 3 Dec 2003, Kendall Bennett wrote: |> |> I have heard many people reference the fact that the although the Linux |> Kernel is under the GNU GPL license, that the code is licensed with an |> exception clause that says binary loadable modules do not have to be |> under the GPL. | |Nope. No such exception exists. | |There's a clarification that user-space programs that use the standard |system call interfaces aren't considered derived works, but even that |isn't an "exception" - it's just a statement of a border of what is |clearly considered a "derived work". User programs are _clearly_ not |derived works of the kernel, and as such whatever the kernel license is |just doesn't matter. | |And in fact, when it comes to modules, the GPL issue is exactly the same. |The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result, |anything that is a derived work has to be GPL'd. It's that simple. (and then goes on to discuss further his own personal opinion) http://kerneltrap.org/node/1735 But you still misunderstand the fundamental problem, and this really needs to be discussed with Red Hat legal. Alan ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2012-04-22 23:10 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-12-15 21:44 [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach Mike Snitzer 2011-12-20 7:31 ` Hannes Reinecke 2012-01-05 15:24 ` Mike Snitzer 2012-04-05 14:47 ` Mike Snitzer 2012-04-20 14:45 ` [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach Mike Snitzer 2012-04-20 15:17 ` James Bottomley 2012-04-20 15:46 ` Mike Snitzer 2012-04-20 15:49 ` Chandra Seetharaman 2012-04-20 17:34 ` [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL Mike Snitzer 2012-04-20 20:41 ` Alan Cox 2012-04-20 21:58 ` Mike Snitzer 2012-04-20 22:20 ` Alan Cox 2012-04-20 22:58 ` Mike Snitzer 2012-04-20 23:14 ` Alan Cox 2012-04-20 23:34 ` Mike Snitzer 2012-04-22 22:13 ` Mike Snitzer 2012-04-22 22:34 ` Alan Cox 2012-04-22 23:01 ` Mike Snitzer 2012-04-22 23:13 ` Alan Cox
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.