From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDuWI-0004Av-KT for qemu-devel@nongnu.org; Tue, 18 Sep 2012 05:55:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDuWH-0008Ax-JZ for qemu-devel@nongnu.org; Tue, 18 Sep 2012 05:55:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47498) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDuWH-00089z-BL for qemu-devel@nongnu.org; Tue, 18 Sep 2012 05:55:05 -0400 Message-ID: <505844F4.6070600@redhat.com> Date: Tue, 18 Sep 2012 11:55:00 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <539633110.1300350.1347959367353.JavaMail.root@redhat.com> <50584184.5080602@redhat.com> <50584385.7060709@redhat.com> In-Reply-To: <50584385.7060709@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] ping Re: [RFC PATCH 00/13] Embedded NBD server List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: stefanha@gmail.com, qemu-devel@nongnu.org, Markus Armbruster Am 18.09.2012 11:48, schrieb Paolo Bonzini: > Il 18/09/2012 11:40, Kevin Wolf ha scritto: >>>>>> Note that after completing the refactoring, we'll only have one combined >>>>>> bdrv_close/delete function and so there won't be BlockDriverStates >>>>>> that are closed. In this case, I think it's quite obvious that not closing >>>>>> the filters wouldn't make any sense. >>>> >>>> Does that mean that any I/O throttling must be applied again on every >>>> medium change? That would be a behavioral change. >> Hm, I guess so, at least on the lowest level. The only thing I know for >> certain is that maintaining compatibility for the old commands will be >> fun, but if possible at all we shouldn't let that compromise our design. > > Yeah, originally we had the idea of a "proxy" driver where you could > stack all your persistent filters. The proxy driver would be needed of > course for removable media, but it could also subsume things like > bdrv_swap and bdrv_append. That would be filters directly for a BlockBackend, which we need in order to support filter that stay on top of snapshots. However, they only help in this specific case if we leave the same BlockBackend around across media change, which wasn't part of the plan, I think. But maybe we'll have to. Kevin