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@xxxxxxxxxx> 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). 4K lines of code is a lot :-) Thank you for taking a look at 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). I was thinking about having it in the drivers/* as ideally it should be a module. You really don't need to have it built in. I am not that worried about you being a bottleneck - I am OK asking two weeks before a merge for you to pull from my tree if I have some patches for it? Or is there some other bottleneck that I am not aware of? > > 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 > reasonable split and history using rebase could probably be contrived > before merging it. <nods> > > -- > Jesse Barnes, Intel Open Source Technology Center > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
