WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

[Xen-devel] Re: [Xen-users] [XCP] domain 0 kernel patch queue published

I've added back xen-devel since this is more of a devel question.
Apologies for the cross post.

On Thu, 2010-03-11 at 15:52 +0000, Matthew Law wrote:
> Ian,
> 
> out of interest, what is covered by "those which are not upstreamable"? -

Generally debugging stuff towards the end of the queue, or in some cases
the end of a section in the queue, some of it has a comment to the
effect "not for upstream" somewhere in the patch header.

The vast majority of the patches in the queue are already backports from
other trees or imports of driver updates. For the driver updates you
would expect them to be upstreamed by their upstream authors not us.

Quickly scanning for obvious not-upstream stuff I see:
      * the final 5 netback patches which are a combination of debugging
        aids and patches to allow older Windows PV drivers to continue
        to work. The latter will be dropped when we think enough time
        has passed to allow people to update to more recent drivers.
      * privcmd support for privilege separation in qemu -- to be
        replaced by qemu-stub.
      * bonding SLB mode -- vswitch contains the same functionality
      * all the debugging stuff at the end

> IIRC, there is code in XCP that forces an I/O flush for consistent
> snapshots which is of particular value.  Will the likes of this be pushed
> up into the pv ops tree?

The block backends are one area of the queue I'm not that familiar with
(and therefore haven't considered in my list above) so I'm not sure
which patch you are referring to or up to date on what the specific
plans are for those patches. From your description it sounds like a
patch which has a future.

I believe the general plan is that blkback and blktap2 stuff is destined
for upstream at some stage. The blktap1 patches will be dropped once XCP
moves to blktap2 (the blktap1 code in this tree is might actually be
better called blktap1.5 -- it's the halfway stage to developing blktap2
and, if I understand right, the effort necessary to upstream was put
into blktap2).

Ian.

> 
> Thanks,
> 
> Matt
> 
> On Thu, March 11, 2010 3:07 pm, Ian Campbell wrote:
> > The kernel patch queue used by the Xen Cloud Platform domain 0 has been
> > published at:
> >         http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg
> >
> > This kernel has been the recipient of extensive testing and performance
> > optimization and is actively maintained with the latest stable drivers.
> >
> > There is ongoing work to merge patches which are not currently upstream
> > into the paravirtops tree or to remove the need for those which are not
> > upstreamable.
> >
> > In order to avoid further divergence we would ask that any submissions
> > to this tree take the form of a backport from something which is already
> > committed to the pvops kernel. XCP will be moving to 2.6.32 the based
> > PVops kernel once it achieves a similar level of testing/performance to
> > the existing kernel.
> >
> > The patch queue is developed against the "v2.6.27" tag in
> > http://kernel.org/hg/linux-2.6/ using the mercurial mq extension:
> >         $ hg clone http://kernel.org/hg/linux-2.6/ linux-2.6.hg
> >         $ cd linux-2.6.hg
> >         $ hg clone http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg
> > .hg/patches
> >         $ hg update v2.6.27
> >         $ hg qpush -a
> >
> > Other patch management systems seem to work although these will be
> > subject to the foibles of the different tools with regard to accepted
> > levels of fuzz etc.
> >
> > The queue current applies using guilt against the "v2.6.27" tag in
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git iff
> > you have a guilt recent enough to ignore comments at the end of lines in
> > the series file (0.30 from Debian Lenny is not new enough, 0.32.2 from
> > Debian Sid is) and manually touch the status file.
> >         $ git clone
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > linux-2.6.git
> >         $ cd linux-2.6.git
> >         $ mkdir .git/patches
> >         $ hg clone http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg
> > .git/patches/master
> >         $ touch .git/patches/status
> >         $ git reset --hard v2.6.27
> >         $ guilt push -a
> >
> > Using quilt against
> > http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.tar.bz2.
> > appears to work but requires you to allow additional fuzz e.g.
> > "QUILT_PATCH_OPTS=-F3 quilt push -a".
> >
> > Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>