Am 19.10.2015 um 16:32 hat Max Reitz geschrieben: > On 19.10.2015 16:18, Kevin Wolf wrote: > > 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? > > We don't? -drive if=none,id=foo works just fine for me. Issuing qemu-io > foo "read 0 512" then prints "read failed: " + strerror(ENOMEDIUM) to > stderr.
Sorry, I meant "no blockdev-add way", i.e. hotplug an empty BB in QMP. > > 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. > > I really wouldn't want to use the BBRS for anything but legacy support > (i.e. change inheriting the options of the last medium)... Fair enough. Then I guess it was a random stupid thought. > > 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? > > Not on the latter part. Pity. Kevin
pgpm29ZPOE3b6.pgp
Description: PGP signature
