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

[Wen Congyang <wency@xxxxxxxxxxxxxx>]

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...

Thanks
Wen Congyang

> 
>  -George
> .
> 


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