qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] BlockDriverState stack and BlockListeners


From: Markus Armbruster
Subject: Re: [Qemu-devel] BlockDriverState stack and BlockListeners
Date: Tue, 21 Feb 2012 17:19:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Kevin Wolf <address@hidden> writes:

> Am 21.02.2012 16:56, schrieb Markus Armbruster:
>> Kevin Wolf <address@hidden> writes:
[...]
>>> Maybe we need to introduce something outside of the whole stack, an
>>> entity that is referred to by the device (as in IDE, virtio-blk, ...)
>>> and that refers to a stack of top-level listeners (which would be moved
>>> to the new top-level BlockSource on live snapshot) and to the first
>>> BlockSource (which can have more listeners, and those would stick with
>>> the same BlockSource even if moves down the chain).
>> 
>> The top-level BDS is already special.  I think it makes sense to factor
>> out the specialness into a "block backend" type, and let it point to a
>> non-special block driver instance (root of a tree of block driver
>> instances, in general).
>
> I think this is what I meant.

Then we're in violent agreement :)

>>> Oh, and just to open another can of worms: We should probably design in
>>> the notion of media (which can be ejected etc.) and drives (which always
>>> stay there). We don't have a clean separation today.
>> 
>> The "closed BDS means no media" thing works, but it's odd.
>
> I'm more talking about data that belongs to the media, like geometry.
> This came up recently with Hervé's floppy patches.

Is geometry relevant to anything but floppies and really small disks
being accessed via really old interfaces?



reply via email to

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