qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Max Reitz
Subject: Re: [Qemu-block] [PATCH v6 18/39] block: Add BlockBackendRootState
Date: Mon, 19 Oct 2015 16:32:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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.

> 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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]