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 10:27:09 -0700
From:	Jon Mason <jon.mason@...el.com>
To:	chetan loke <loke.chetan@...il.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.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 12:02:20PM -0400, chetan loke 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.
> 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.

I don't see the benefit of having the driver in staging.  Any vendors
who would notice the ntb driver in staging would be sitting on these
mailing lists and hopefully have planety of comments on the design.
Stashing the driver in staging while waiting for these comments (which
may never come) doesn't seem the best course of action.

Thanks,
Jon

> 
> 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