From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiUSe-0006IB-9z for qemu-devel@nongnu.org; Tue, 22 Mar 2016 18:07:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiUSZ-00049N-Au for qemu-devel@nongnu.org; Tue, 22 Mar 2016 18:07:36 -0400 Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]:33848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiUSZ-00048v-3p for qemu-devel@nongnu.org; Tue, 22 Mar 2016 18:07:31 -0400 Received: by mail-wm0-x243.google.com with SMTP id p65so91820wmp.1 for ; Tue, 22 Mar 2016 15:07:31 -0700 (PDT) Sender: Paolo Bonzini References: <1456151945-11225-1-git-send-email-pbonzini@redhat.com> <1456151945-11225-4-git-send-email-pbonzini@redhat.com> <87k2kvzu0z.fsf@blackfin.pond.sub.org> <56F01F8A.2090902@redhat.com> <87shzj68n2.fsf@blackfin.pond.sub.org> <56F030B3.3070709@redhat.com> <87fuvj1ywx.fsf@blackfin.pond.sub.org> <20160322081910.GA4222@noname.redhat.com> <87d1qmreqz.fsf@blackfin.pond.sub.org> From: Paolo Bonzini Message-ID: <56F1C220.4000705@redhat.com> Date: Tue, 22 Mar 2016 23:07:28 +0100 MIME-Version: 1.0 In-Reply-To: <87d1qmreqz.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] block: remove legacy_dinfo at blk_detach_dev time List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Kevin Wolf Cc: qemu-devel@nongnu.org, Max Reitz On 22/03/2016 11:25, Markus Armbruster wrote: > Regardless of how and when we create BlockBackend, we'll want to keep > the clean separation between frontend and backend internally and at the > user interface. This means that the BlockBackend should not own the DriveInfo. The backend and frontend need not know of the object that mixes concepts from both of them. Instead, the DriveInfo can instantiate itself into a BlockBackend and the board can (if required) use the frontend parts of DriveInfo to instantiate a device and connect it to the BlocKBackend. In Kevin's idea there would be no ownership either way. Until then, I think my patch actually gets us closer to the ideal. Paolo > DriveInfo has no role in cleanly separate creation of frontend and > backend now, and it shouldn't get one in the future. Its purpose is to > support the legacy user interface that has frontend and backend matters > mixed up.