[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d96d36-fd13-2268-122b-fea806090942@nvidia.com>
Date: Fri, 2 Sep 2022 00:02:19 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Jens Axboe <axboe@...nel.dk>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the mm tree with the block tree
On 9/1/22 07:10, Jens Axboe wrote:
>> So I see two obvious solutions. Either:
>>
>> a) Only do the first two patches for now, and leave them in Andrew's
>> tree. After the next release, do the remaining 5 patches via the block
>> tree, or
>>
>> b) Move the whole series to the block tree now, or
>>
>> c) something else?
>>
>> Andrew, Jens, any preference here?
>
> Would've been cleaner to take through the block tree given what
> it touches, imho. Or at least base on that, so we'd avoid frivolous
> conflicts like this.
>
OK, so I'm new to block, and my first guess at the right git tree
and branch:
git://git.kernel.dk/linux-block block-6.0
doesn't seem to contain this one:
e88811bc43b9 ("block: use on-stack page vec for <= UIO_FASTIOV")
Can you point me to the right tree please?
Once I know the right block tree to use, I could post the next version
rebased on top of that. And plan to send it up through Jens' block tree,
assuming that it continues to survive the reviews, that is.
Andrew, is that OK with you? The first two patches will still get
reviewed by mm, and they shouldn't conflict with mm, even if they
go up through the block tree.
thanks,
--
John Hubbard
NVIDIA
Powered by blists - more mailing lists