netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 31 Jul 2012 12:02:20 -0400
From:	chetan loke <loke.chetan@...il.com>
To:	Bjorn Helgaas <bhelgaas@...gle.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 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.
And since this is the first NTB part for which the support is
introduced the class driver design could be a moving target. As
someone else mentioned, the async/sync tx-dma is another hook that
could change the class driver's design.


> driver for their hardware just to incorporate a PLX bug fix?  Will
> users of PLX hardware accept a new driver release that only benefits
> Intel users?

May be till the class driver is stable, the client(intel/PLX) drivers
might have to be modified.  This is a cue for other vendors to
chime-in and review this design?
Just thinking if this could sit in staging for some time(so that
others get a chance to review/suggest changes as well) and then get
promoted out of staging.

Chetan Loke
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html