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

[Wen Congyang <wency@cn.fujitsu.com>]

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@cn.fujitsu.com> 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...

Thanks
Wen Congyang

> 
>  -George
> .
>