diff for duplicates of <000401d2f114$3499f2b0$9dcdd810$@dell.com> diff --git a/a/1.txt b/N1/1.txt index 7e44808..0cc2fdf 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,41 +1,29 @@ From: Logan Gunthorpe > On 6/29/2017 12:11 PM, Allen Hubbe wrote: -> > Nak. This breaks a work around for stability issues on some = -hardware. I am ok with changing the -> comment to say, this is only supported when called after link up. I = -would still like to allow these -> to be called at any time. Specific hardware drivers like Switchtec = -may return an error. Upstream -> drivers, of course, should call these after link up: patch 5/16 part = -of this set looks good. ->=20 -> If absolutely necessary I can leave this out. But in terms of = -interface -> design it's _so_ much better to have it in. This change would bring = -the +> > Nak. This breaks a work around for stability issues on some hardware. I am ok with changing the +> comment to say, this is only supported when called after link up. I would still like to allow these +> to be called at any time. Specific hardware drivers like Switchtec may return an error. Upstream +> drivers, of course, should call these after link up: patch 5/16 part of this set looks good. +> +> If absolutely necessary I can leave this out. But in terms of interface +> design it's _so_ much better to have it in. This change would bring the > score from a 3 to a 5 on Rusty Russel's Hard to Misuse ranking[1]. To > quote Rusty: ->=20 +> > "3. Read the documentation and you'll get it right. -> People only read instructions after they've already tied themselves = -into -> a knot. Then they skim them for keywords and don't read your warnings. = -I -> don't give an example of this; if this is the best an interface can = -get +> People only read instructions after they've already tied themselves into +> a knot. Then they skim them for keywords and don't read your warnings. I +> don't give an example of this; if this is the best an interface can get > do, it's in trouble." ->=20 +> > Can someone not just fix the out-of-tree code? And since when is > out-of-tree code reasonable justification for what's done in upstream? -Unfortunately, it is to work around hardware errata. That is not so = -trivial to fix. +Unfortunately, it is to work around hardware errata. That is not so trivial to fix. -The workaround in software is also not acceptable upstream, for doing = -things like writing directly to the peer's interrupt controller = -registers, bypassing the ntb doorbells. +The workaround in software is also not acceptable upstream, for doing things like writing directly to the peer's interrupt controller registers, bypassing the ntb doorbells. ->=20 +> > Logan ->=20 +> > [1]http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html diff --git a/a/content_digest b/N1/content_digest index 1d9116c..be3b915 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,9 +6,9 @@ "Subject\0RE: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align\0" "Date\0Thu, 29 Jun 2017 16:13:40 -0400\0" "To\0'Logan Gunthorpe' <logang@deltatee.com>" - <linux-ntb@googlegroups.com> - <linux-pci@vger.kernel.org> - " <linux-kernel@vger.kernel.org>\0" + linux-ntb@googlegroups.com + linux-pci@vger.kernel.org + " linux-kernel@vger.kernel.org\0" "Cc\0'Jon Mason' <jdmason@kudzu.us>" 'Dave Jiang' <dave.jiang@intel.com> 'Bjorn Helgaas' <bhelgaas@google.com> @@ -20,44 +20,32 @@ "b\0" "From: Logan Gunthorpe\n" "> On 6/29/2017 12:11 PM, Allen Hubbe wrote:\n" - "> > Nak. This breaks a work around for stability issues on some =\n" - "hardware. I am ok with changing the\n" - "> comment to say, this is only supported when called after link up. I =\n" - "would still like to allow these\n" - "> to be called at any time. Specific hardware drivers like Switchtec =\n" - "may return an error. Upstream\n" - "> drivers, of course, should call these after link up: patch 5/16 part =\n" - "of this set looks good.\n" - ">=20\n" - "> If absolutely necessary I can leave this out. But in terms of =\n" - "interface\n" - "> design it's _so_ much better to have it in. This change would bring =\n" - "the\n" + "> > Nak. This breaks a work around for stability issues on some hardware. I am ok with changing the\n" + "> comment to say, this is only supported when called after link up. I would still like to allow these\n" + "> to be called at any time. Specific hardware drivers like Switchtec may return an error. Upstream\n" + "> drivers, of course, should call these after link up: patch 5/16 part of this set looks good.\n" + "> \n" + "> If absolutely necessary I can leave this out. But in terms of interface\n" + "> design it's _so_ much better to have it in. This change would bring the\n" "> score from a 3 to a 5 on Rusty Russel's Hard to Misuse ranking[1]. To\n" "> quote Rusty:\n" - ">=20\n" + "> \n" "> \"3. Read the documentation and you'll get it right.\n" - "> People only read instructions after they've already tied themselves =\n" - "into\n" - "> a knot. Then they skim them for keywords and don't read your warnings. =\n" - "I\n" - "> don't give an example of this; if this is the best an interface can =\n" - "get\n" + "> People only read instructions after they've already tied themselves into\n" + "> a knot. Then they skim them for keywords and don't read your warnings. I\n" + "> don't give an example of this; if this is the best an interface can get\n" "> do, it's in trouble.\"\n" - ">=20\n" + "> \n" "> Can someone not just fix the out-of-tree code? And since when is\n" "> out-of-tree code reasonable justification for what's done in upstream?\n" "\n" - "Unfortunately, it is to work around hardware errata. That is not so =\n" - "trivial to fix.\n" + "Unfortunately, it is to work around hardware errata. That is not so trivial to fix.\n" "\n" - "The workaround in software is also not acceptable upstream, for doing =\n" - "things like writing directly to the peer's interrupt controller =\n" - "registers, bypassing the ntb doorbells.\n" + "The workaround in software is also not acceptable upstream, for doing things like writing directly to the peer's interrupt controller registers, bypassing the ntb doorbells.\n" "\n" - ">=20\n" + "> \n" "> Logan\n" - ">=20\n" + "> \n" > [1]http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html -5541bf48cca2f12b4c2ba08c263ff394d1cd0b2794c68c8e03bc0b26c71c7603 +7c55a336604c1f335b41ba9218e83b3a53447a7efacb2967adf6a68ff6bae80d
diff --git a/a/1.txt b/N2/1.txt index 7e44808..0cc2fdf 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,41 +1,29 @@ From: Logan Gunthorpe > On 6/29/2017 12:11 PM, Allen Hubbe wrote: -> > Nak. This breaks a work around for stability issues on some = -hardware. I am ok with changing the -> comment to say, this is only supported when called after link up. I = -would still like to allow these -> to be called at any time. Specific hardware drivers like Switchtec = -may return an error. Upstream -> drivers, of course, should call these after link up: patch 5/16 part = -of this set looks good. ->=20 -> If absolutely necessary I can leave this out. But in terms of = -interface -> design it's _so_ much better to have it in. This change would bring = -the +> > Nak. This breaks a work around for stability issues on some hardware. I am ok with changing the +> comment to say, this is only supported when called after link up. I would still like to allow these +> to be called at any time. Specific hardware drivers like Switchtec may return an error. Upstream +> drivers, of course, should call these after link up: patch 5/16 part of this set looks good. +> +> If absolutely necessary I can leave this out. But in terms of interface +> design it's _so_ much better to have it in. This change would bring the > score from a 3 to a 5 on Rusty Russel's Hard to Misuse ranking[1]. To > quote Rusty: ->=20 +> > "3. Read the documentation and you'll get it right. -> People only read instructions after they've already tied themselves = -into -> a knot. Then they skim them for keywords and don't read your warnings. = -I -> don't give an example of this; if this is the best an interface can = -get +> People only read instructions after they've already tied themselves into +> a knot. Then they skim them for keywords and don't read your warnings. I +> don't give an example of this; if this is the best an interface can get > do, it's in trouble." ->=20 +> > Can someone not just fix the out-of-tree code? And since when is > out-of-tree code reasonable justification for what's done in upstream? -Unfortunately, it is to work around hardware errata. That is not so = -trivial to fix. +Unfortunately, it is to work around hardware errata. That is not so trivial to fix. -The workaround in software is also not acceptable upstream, for doing = -things like writing directly to the peer's interrupt controller = -registers, bypassing the ntb doorbells. +The workaround in software is also not acceptable upstream, for doing things like writing directly to the peer's interrupt controller registers, bypassing the ntb doorbells. ->=20 +> > Logan ->=20 +> > [1]http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html diff --git a/a/content_digest b/N2/content_digest index 1d9116c..f735d88 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -20,44 +20,32 @@ "b\0" "From: Logan Gunthorpe\n" "> On 6/29/2017 12:11 PM, Allen Hubbe wrote:\n" - "> > Nak. This breaks a work around for stability issues on some =\n" - "hardware. I am ok with changing the\n" - "> comment to say, this is only supported when called after link up. I =\n" - "would still like to allow these\n" - "> to be called at any time. Specific hardware drivers like Switchtec =\n" - "may return an error. Upstream\n" - "> drivers, of course, should call these after link up: patch 5/16 part =\n" - "of this set looks good.\n" - ">=20\n" - "> If absolutely necessary I can leave this out. But in terms of =\n" - "interface\n" - "> design it's _so_ much better to have it in. This change would bring =\n" - "the\n" + "> > Nak. This breaks a work around for stability issues on some hardware. I am ok with changing the\n" + "> comment to say, this is only supported when called after link up. I would still like to allow these\n" + "> to be called at any time. Specific hardware drivers like Switchtec may return an error. Upstream\n" + "> drivers, of course, should call these after link up: patch 5/16 part of this set looks good.\n" + "> \n" + "> If absolutely necessary I can leave this out. But in terms of interface\n" + "> design it's _so_ much better to have it in. This change would bring the\n" "> score from a 3 to a 5 on Rusty Russel's Hard to Misuse ranking[1]. To\n" "> quote Rusty:\n" - ">=20\n" + "> \n" "> \"3. Read the documentation and you'll get it right.\n" - "> People only read instructions after they've already tied themselves =\n" - "into\n" - "> a knot. Then they skim them for keywords and don't read your warnings. =\n" - "I\n" - "> don't give an example of this; if this is the best an interface can =\n" - "get\n" + "> People only read instructions after they've already tied themselves into\n" + "> a knot. Then they skim them for keywords and don't read your warnings. I\n" + "> don't give an example of this; if this is the best an interface can get\n" "> do, it's in trouble.\"\n" - ">=20\n" + "> \n" "> Can someone not just fix the out-of-tree code? And since when is\n" "> out-of-tree code reasonable justification for what's done in upstream?\n" "\n" - "Unfortunately, it is to work around hardware errata. That is not so =\n" - "trivial to fix.\n" + "Unfortunately, it is to work around hardware errata. That is not so trivial to fix.\n" "\n" - "The workaround in software is also not acceptable upstream, for doing =\n" - "things like writing directly to the peer's interrupt controller =\n" - "registers, bypassing the ntb doorbells.\n" + "The workaround in software is also not acceptable upstream, for doing things like writing directly to the peer's interrupt controller registers, bypassing the ntb doorbells.\n" "\n" - ">=20\n" + "> \n" "> Logan\n" - ">=20\n" + "> \n" > [1]http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html -5541bf48cca2f12b4c2ba08c263ff394d1cd0b2794c68c8e03bc0b26c71c7603 +83a00980d9748b19907fea461fa89f720afeed3a1051b073257fae16c5b80f69
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.