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]
Message-ID: <20110531100040.60ade056@jbarnes-desktop>
Date:	Tue, 31 May 2011 10:00:40 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	linux-pci@...r.kernel.org, xen-devel@...ts.xensource.com,
	linux-kernel@...r.kernel.org, konrad@...nel.org
Subject: Re: [Xen-devel] Re: [PATCH v6] xen pci backend driver.

On Fri, 27 May 2011 11:22:20 -0400
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:

> On Mon, Apr 25, 2011 at 11:58:50AM -0700, Jesse Barnes wrote:
> > On Wed, 20 Apr 2011 17:07:19 -0400
> > Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> > 
> > > The following patch implements the Xen pci backend for upstream Linux.
> > > This is the host side counterpart to the frontend driver in
> > > drivers/pci/xen-pcifront.c. The PV protocol is also implemented by
> > > frontend drivers in other OSes too, such as the BSDs.
> > > 
> > > This driver has a long history as an out of tree driver but I am
> > > submitting it here as a single monolithic patch to aid review. Once it
> > > has been reviewed and is considered suitable for merging can we perhaps
> > > consider merging the equivalent git branch which maintains much of
> > > history?
> > 
> > It looks pretty clean at first glance (though 128k worth of patch isn't
> > an ideal way to split it).
> > 
> > But maybe the back end belongs in arch/x86/xen as it's really a arch
> > specific PCI implementation at heart?  I don't want to be a bottleneck
> > for any Xen specific PCI patches in the future, and other arches have a
> > similar split (though not always with an ideal core vs arch split).
> 
> Jesse,
> 
> Xen has a drivers/xen directory. In the past we have put some of the
> "backends" in there, such as the SWIOTLB one. Perhaps some of it (or all?)
> of this driver should go in there? If you are OK with this I can do it
> that way and start chasing folks to review this driver?

Yeah, I'm fine with that.  Each arch typically has a chunk of PCI code
under arch/ anyway (some more than others), so doing it that way is ok
with me.
 
> > Figuring out some way to preserve the git history is probably a good
> > idea, assuming it's not too much of a mess.  If it is, a more
> 
> I tried to keep it clean.. Most of the stuff is from me thought so I might
> as well just squash it in one.

Yeah that's up to you; presumably you just want to preserve the useful
parts of the history, or maybe just make the initial changelog big
enough to include all the important bits you've learned over the
years. :)

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ