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

[Kevin Wolf]

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

Re: [Qemu-block] [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 
> > 
> > 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


pgp0MNvJfQJnr.pgp
Description: PGP signature

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

[Max Reitz]

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 
> 
> 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.

> 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)...

> 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.

Max



signature.asc
Description: OpenPGP digital signature