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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

I'm working on a talk for the Linux Collab Summit next week; and after that I'm 
on holiday for about a week.  (Actually I'm in Hong Kong for the tail end of 
Chinese New Year!)

At any rate, I won't get a chance to look at this until March at the earliest.

 -George
________________________________________
From: Hongyang Yang [yanghy@xxxxxxxxxxxxxx]
Sent: 13 February 2015 06:56
To: George Dunlap; Wen Congyang
Cc: Ian Jackson; Lai Jiangshan; Jiang Yunhong; Eddie Dong; xen devel; Ian 
Campbell
Subject: 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