Thread (26 messages) 26 messages, 7 authors, 2012-08-02

Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support

From: Bjorn Helgaas <bhelgaas@google.com>
Date: 2012-07-31 17:04:08
Also in: linux-pci, lkml

On Tue, Jul 31, 2012 at 10:02 AM, chetan loke [off-list ref] wrote:
On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas [off-list ref] wrote:
quoted
On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason [off-list ref] wrote:
quoted
I've tried to make it all generic enough that non-Intel NTBs should plug in with
minimal changes to ntb_hw.c.  If their design is too divergent, then a slight
redesign of ntb_hw.c might be necessary.  But from what I've seen of other
designs on the internet, they appear to be extremely similar.  The transport and
client drivers were written with the hardware abstracted away as much as
possible to prevent the need to modify it for different hardware.  If there is
anything which is Intel hardware specific, I'd be happy to change it to make it
more generic.
That makes sense from a technical point of view, but I think it's
going to cause maintenance issues.  For example, assume PLX NTB
support is added.  Will PLX be happy about having to convince you to
accept changes?  Will Intel be happy about having to release a new
Do you mean convince Intel? Well, if we think of ntb as the class
driver then the onus is on the community to vet the changes and NOT
intel.
No, I said convince "you," meaning *Jon*.  Intel doesn't apply
patches.  "The community" doesn't apply patches.  Jon applies patches.
 This has nothing to do with the fact that Jon is employed by Intel.
The point is that when you have multiple organizations involved, they
have different goals, markets, customers, and schedules.  If one
module contains both Intel-specific and PLX-specific things, that's a
place where these organizational differences may cause issues,
regardless of who is applying the patches.

Obviously it's not a problem now, and maybe it will never be.  But I
think there's a possibility.  Since I have no direct interest in any
of these devices, I'm only raising that possibility, not trying to
force any particular direction.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help