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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Jul 2012 11:03:40 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	chetan loke <loke.chetan@...il.com>
Cc:	Jon Mason <jon.mason@...el.com>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, linux-pci@...r.kernel.org,
	Dave Jiang <dave.jiang@...el.com>
Subject: Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support

On Tue, Jul 31, 2012 at 10:02 AM, chetan loke <loke.chetan@...il.com> wrote:
> On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@...el.com> wrote:
>>>
>>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/