From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: upstream merge status for 2.6.35, .36? Date: Wed, 4 Aug 2010 16:11:00 -0400 Message-ID: <20100804201100.GA16839@phenom.dumpdata.com> References: <20100604223929.GA8819@orion.carnet.hr> <4C099836.1050903@goop.org> <20100607074811.GV17817@reaktio.net> <20100607083201.GA16443@orion.carnet.hr> <20100607145743.GB5085@phenom.dumpdata.com> <20100804194457.GA6914@orion.carnet.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20100804194457.GA6914@orion.carnet.hr> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Josip Rodin Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wed, Aug 04, 2010 at 09:44:57PM +0200, Josip Rodin wrote: > On Mon, Jun 07, 2010 at 10:57:43AM -0400, Konrad Rzeszutek Wilk wrote: > > So the SWIOTLB is 1 out 3. The next component is: > > > > 2). Xen SWIOTLB. This is the xen swiotlb code that utilizes the swiotlb > > proper that was just made generic enough to be used in this capacity. > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb-2.6.git xen-swiotlb-0.8.2 > > > > 3). and then the Xen PCI front. Which utilizes the Xen-SWIOTLB (and also > > the Xen PCI), to well, allow guests to have PCI devices passed in. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git pv/pcifront-2.6.34 > > > > The 2) and 3) are mostly Xen specific so they should be much more palpable > > than the first one. > > JFTR these now look to be: > > http://lkml.org/lkml/2010/8/2/289 [ SWIOTLB GIT PULL ] > http://lkml.org/lkml/2010/7/27/246 [ Xen-SWIOTLB] > http://lkml.org/lkml/2010/8/4/374 [ RFC Xen PCI patches] > > But in the latter you wrote that you don't expect #2 to get in the 2.6.36 > merge window. Why? I saw a single tentative complaint from hpa on one No. The #2 is right now brewing in linux-next and I am thinking to ask Linus to pull it next week. > particular patch, but at the end of that subthread you all agreed that it > was acceptable because it's small and no worse than the currently included > code. Do you expect Linus to ignore the pull request because of that, or? It is #3 that I am not expecting to get in 2.6.36 merge window, b/c well, I just posted it now for review and the runway is way to short for that. But now re-reading my email " patches utilize the Xen-SWIOTLB library (http://lkml.org/lkml/2010/7/27/246) and I don't expect them to get in the 2.6.36 merge window." it does sound like I am refering to Xen-SWIOTLB, which is not what I meant. Argh. Thanks for noticing it.