From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbqVv-000495-4E for qemu-devel@nongnu.org; Fri, 23 Nov 2012 05:29:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbqVn-000260-Kh for qemu-devel@nongnu.org; Fri, 23 Nov 2012 05:29:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbqVn-00025R-BR for qemu-devel@nongnu.org; Fri, 23 Nov 2012 05:29:31 -0500 Message-ID: <50AF5007.4030505@redhat.com> Date: Fri, 23 Nov 2012 11:29:27 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1353488464-82756-1-git-send-email-dietmar@proxmox.com> <50ACB184.5080204@redhat.com> <24E144B8C0207547AD09C467A8259F755782D8A1@lisa.maurer-it.com> <50ACCAEC.2030001@redhat.com> <24E144B8C0207547AD09C467A8259F755782F79B@lisa.maurer-it.com> <50AF3D23.2010909@redhat.com> <24E144B8C0207547AD09C467A8259F755782FA23@lisa.maurer-it.com> <24E144B8C0207547AD09C467A8259F755782FA71@lisa.maurer-it.com> In-Reply-To: <24E144B8C0207547AD09C467A8259F755782FA71@lisa.maurer-it.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/5] RFC: Efficient VM backup for qemu (v1) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dietmar Maurer Cc: Paolo Bonzini , "qemu-devel@nongnu.org" Am 23.11.2012 10:31, schrieb Dietmar Maurer: >>>>> Filters would be implemented as BlockDrivers, i.e. you could >>>>> implement >>>>> .bdrv_co_write() in a filter to intercept all writes to an image. >>>> >>>> I am quite unsure if that make things easier. >>> >>> At least it would make for a much cleaner design compared to putting >>> code for every feature you can think of into bdrv_co_do_readv/writev(). >> >> So if you want to add a filter, you simply modify bs->drv to point to the filter? > > Seems the BlockDriver struct does not contain any 'state' (I guess that is by design), > so where do you store filter related dynamic data? You wouldn't change bs->drv of the block device, you still need that one after having processed the data in the filter. Instead, you'd have some BlockDriverState *first_filter in bs to which requests are forwarded. first_filter->file would point to either the next filter or if there are no more filters to the real BlockDriverState. Which raises the question of how to distinguish whether it's a new request to bs that must go through the filters or whether it actually comes from the last filter in the chain. As you can see, we don't have a well thought out plan yet, just rough ideas (otherwise it would probably be implemented already). Kevin