From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agYHd-0002PT-Mt for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:48:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agYHc-0008Ez-Cn for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:48:13 -0400 References: <1455645388-32401-1-git-send-email-pbonzini@redhat.com> <20160316181819.GD2012@stefanha-x1.localdomain> <56E9DE2E.5060607@redhat.com> <20160317134430.GJ14062@stefanha-x1.localdomain> From: Paolo Bonzini Message-ID: <56EAB590.1020403@redhat.com> Date: Thu, 17 Mar 2016 14:48:00 +0100 MIME-Version: 1.0 In-Reply-To: <20160317134430.GJ14062@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 00/16] AioContext fine-grained locking, part 1 of 3, including bdrv_drain rewrite List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, Stefan Hajnoczi On 17/03/2016 14:44, Stefan Hajnoczi wrote: > > For example, each part will probably have an uncontroversial and > > generally useful prefix---for example patches 1-4 in this case, or th= e > > change to a single linux-aio context per iothread. You could merge > > those only, and for the rest, I will maintain myself a branch with R-= b > > from maintainers. Master will be periodically merged into it, but no= t > > too frequently---it could be only after each part is accepted, or whe= n > > there is some important bugfix to catch. Once the whole multiqueue > > thing gets somewhere I would send you a pull request with the entire > > feature, which would consist of say 200 patches all with a Reviewed-b= y > > already. > >=20 > > This is just a possibility; if you have any other idea, I'd be happy = to > > follow it. > > That sounds reasonable. I guess you are sending a) infrastructure and = safe > changes alongside b) longer-term work. If you indicate which patches > are a) then that makes it easier to merge parts into qemu.git before al= l > the long-term work is complete. Great, let's try it then. For this series (well, for v2 of this series) only patches 1-4 would be considered infrastructure. They were sent before soft freeze, would they be acceptable for 2.6? In general I would send "safe" patches as [PATCH mm/nn] and everything else as [PATCH multiqueue mm/nn] or similar, but in either case I'd be seeking formal maintainer review as soon as I send them. Paolo