Re: [Qemu-devel] [PATCH v6 18/39] block: Add BlockBackendRootState

[Kevin Wolf]

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 <address@hidden>
> > 
> > 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

pgpGX6m1Za8oT.pgp
Description: PGP signature