[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 2/2] make blkback driver handle trim request
>>> On 10.08.11 at 16:37, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 10/08/2011 14:58, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>>>> On 10.08.11 at 15:45, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>>> On Wed, 2011-08-10 at 12:40 +0100, Pasi KÃrkkÃinen wrote:
>>>> Also: Shouldn't this be against upstream Linux 3.x these days, aswell,
>>>> now when both blkback and blkfront are upstream?
>>> Yes, please.
>>> Ideally we would insist that patches to those classic-Xen trees which
>>> are still somewhat maintained be sent to upstream first where applicable
>>> (i.e. only accept "backports" or classic-Xen specific bug fixes).
>> Ideally yes. But that's not generally feasible, at least not always. For
>> instance, I'm glad if I can keep on top of all the things needed for our
>> kernels and hypervisors, and I would at best find time to compile test
>> code for pv-ops. But with only that I certainly shouldn't really submit
> I suspect that by now you are the only direct consumers of 2.6.18-xen. Is
> there really any benefit to keeping the public tree now? Only you commit to
> it; I expect only you directly inherit from it (others might indirectly, I
> accept). I really don't think we should be tempting anyone else to actually
> *use* it as is. Hence my conclusion we could just delete the damn thing.
It's convenient to me, as this way I don't have to deal with a rapidly
growing set of individual patches. But if the tree went dead (I wouldn't
really want to see it deleted, so one can still use it for archaeological
purposes), we would certainly survive.
Xen-devel mailing list