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 <mre...@redhat.com>
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
