Re: upstream merge status for 2.6.35, .36?

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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.