Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Nov 03, 2014 at 06:07:06PM +0800, Wen Congyang wrote:
> On 11/03/2014 05:58 PM, George Dunlap wrote:
> > On 10/29/2014 05:49 AM, Wen Congyang wrote:
> >> On 10/20/2014 10:25 PM, George Dunlap wrote:
> >>> On Wed, Oct 15, 2014 at 2:05 AM, Wen Congyang <wency@xxxxxxxxxxxxxx> 
> >>> wrote:
> >>>> On 10/14/2014 11:48 PM, Ian Jackson wrote:
> >>>>> Wen Congyang writes ("[PATCH 00/17] blktap2 related bugfix patches"):
> >>>>>> These bugs are found when we implement COLO, or rebase
> >>>>>> COLO to upstream xen. They are independent patches, so
> >>>>>> post them in separate series.
> >>>>> blktap2 is unmaintained AFAICT.
> >>>>>
> >>>>> In the last year there has been only one commit which shows evidence
> >>>>> of someone caring even slightly about tools/blktap2/.  The last
> >>>>> substantial attention was in March 2013.
> >>>>>
> >>>>> (I'm disregarding commits which touch tools/blktap2/ to fix up compile
> >>>>> problems with new compilers, sort out build system and file
> >>>>> rearrangements, etc.)
> >>>>>
> >>>>> The file you are touching in your 01/17 was last edited (by anyone, at
> >>>>> all) in January 2010.
> >>>>>
> >>>>> Under the circumstances, we should probably take all these changes
> >>>>> without looking for anyone to ack them.
> >>>>>
> >>>>> Perhaps you would like to become the maintainers of blktap2 ? :-)
> >>>> Hmm, I don't have any knowledge about disk format, but blktap2 have
> >>>> such codes(For example: block-vhd.c, block-qcow.c...). I think I can
> >>>> maintain the rest codes.
> >>> Congyang, were you aware that XenServer has a fork of blktap is
> >>> actually still under active development and maintainership outside of
> >>> the main Xen tree?
> >>>
> >>> git://github.com/xen-org/blktap.git
> >>>
> >>> Both CentOS and Fedora are actually using snapshots of the "blktap2"
> >>> branch in that tree for their Xen RPMs.  (I'm sure CentOS is, I
> >>> believe Fedora is.)  It's not unlikely that the bugs you're fixing
> >>> here have already been fixed in the XenServer fork.
> >> I have another question:
> >> Why we don't merge the "blktap2' branch into xen upstream periodically?
> > 
> > I take it you've found blktap "2.5" useful? :-)
> > 
> > I've been meaning to write an e-mail about this.
> > 
> > The basic reason is that it's normally up to the people doing the 
> > development to submit changes upstream.  Some years ago XenServer forked 
> > the blktap2 codebase but got behind in upstreaming things; at this point 
> > there are far too many changes to simply push them upstream.  Furthermore, 
> > even XenServer isn't 100% sure what they're going to do in the future; as 
> > of a year ago they were planning to get rid of blktap entirely in favor of 
> > another solution.
> > 
> > One of the ideas I'm going to discuss in my e-mail is the idea of treating 
> > blktap2.5 (and/or blktap3) as an external upstream project, similar to the 
> > way that we treat qemu, seabios, ipxe, and ovmf. That would have a similar 
> > effect to what you describe.
> 
> I agree with this. Currently, we have blktap2 and blktap2.5. I don't know my 
> work should be for which
> version...

The one that has an active maintainer!

I presume 'blktap2.5' fits in that category? But we would need to sync
the checkout of blktap2.5 in the Xen git tree when building - so that is
definite Xen 4.6 material.

> 
> Thanks
> Wen Congyang
> 
> > 
> >  -George
> > .
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel