From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoBGq-0003c2-5Y for qemu-devel@nongnu.org; Mon, 19 Oct 2015 10:18:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoBGp-0003zT-AO for qemu-devel@nongnu.org; Mon, 19 Oct 2015 10:18:40 -0400 Date: Mon, 19 Oct 2015 16:18:31 +0200 From: Kevin Wolf Message-ID: <20151019141831.GE5408@noname.redhat.com> References: <1444680042-13207-1-git-send-email-mreitz@redhat.com> <1444680042-13207-19-git-send-email-mreitz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1444680042-13207-19-git-send-email-mreitz@redhat.com> Subject: Re: [Qemu-devel] [PATCH v6 18/39] block: Add BlockBackendRootState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Alberto Garcia , qemu-block@nongnu.org, John Snow , qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi Am 12.10.2015 um 22:00 hat Max Reitz geschrieben: > This structure will store some of the state of the root BDS if the BDS > tree is removed, so that state can be restored once a new BDS tree is > inserted. > > Signed-off-by: Max Reitz Random thought, not directly related to this series: We currently don't have a way to create just a BlockBackend with no medium. If we were to add that, would we want that to be just like a missing -drive file=... option, or would it actually make sense to specify the BlockBackendRootState? If we want to do that, we might actually have found a reason why the 'options' key makes sense in blockdev-add. We could make it a union where you either describe a BlockBackendRootState or a BDS. Another related question is whether we want to separate out BB options (which would otherwise be shared between the BBRS and BDS variants) into their own dict. This dict could be optional and that would be the way to specify whether you want a BB on top or not. Candidates for this dict are id/rerror/werror. There are more fields that exist in both the BDS and BBRS variants, but don't really belong to the BB (i.e. they end up in the real BBRS and not in the BB, and are only valid as long as no BDS is attached). These would not be moved to the BB options dict. Any opinions? Kevin