[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 18/39] block: Add BlockBackendRootState
From: |
Max Reitz |
Subject: |
Re: [Qemu-devel] [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
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH v6 10/39] hw/block/fdc: Implement tray status, (continued)
- [Qemu-devel] [PATCH v6 10/39] hw/block/fdc: Implement tray status, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 11/39] hw/usb-storage: Check whether BB is inserted, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 12/39] block: Fix BB AIOCB AioContext without BDS, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 13/39] block: Move guest_block_size into BlockBackend, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 15/39] block: Move BlockAcctStats into BlockBackend, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 16/39] block: Move I/O status and error actions into BB, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 17/39] block/throttle-groups: Make incref/decref public, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 19/39] block: Make some BB functions fall back to BBRS, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 18/39] block: Add BlockBackendRootState, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 20/39] block: Fail requests to empty BlockBackend, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 24/39] blockdev: Do not create BDS for empty drive, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 23/39] block: Prepare for NULL BDS, Max Reitz, 2015/10/12
- [Qemu-devel] [PATCH v6 25/39] blockdev: Pull out blockdev option extraction, Max Reitz, 2015/10/12