[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 00/17] blktap2 related bugfix patches
Hi George,
å 11/03/2014 05:58 PM, George Dunlap åé:
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.
How is this going?
-George
.
--
Thanks,
Yang.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
