Re: [Qemu-devel] BlockDriverState stack and BlockListeners

[Paolo Bonzini <pbonzini@redhat.com>]

On 02/21/2012 01:22 PM, Stefan Hajnoczi wrote:
> This is a good discussion because BlockDriverState has become bloated
> and complex.  A lot of fields only apply to sub-cases and we should
> really split this struct.
> 
> Fields like "backing_file" *should* be in generic code, not duplicated
> in each Format.  But BlockDriverState is too generic since it also
> encompasses Protocols and Listeners.

Yes.

> You mentioned that some of these classes would be "internal".  I think
> everything should be exposed in the QOM just like Linux exposes kernel
> objects in sysfs.  It makes troubleshooting and debugging easier.

Yes, exposing in QOM makes sense.  But QOM can see all things internal
by design. :)  The question is more what to expose to the rest of QEMU.
 For me the answer would be: BlockSource to the device and monitor,
Format to the monitor only.

> As has been pointed out, "Listener" suggests a passive role.  Perhaps
> BlockFilter, BlockProcessor, or BlockModule is a better name.

BlockFilter sounds good.

> Ideally Formats can be isolated from the rest of the block layer so
> that it becomes easy to create a libimageformat.  If we bake
> coroutines, I/O APIs, and memory allocation functions too deeply into
> Formats then they are hard to test and impossible to use outside of
> QEMU.

I'm afraid that the only way to do this is to first replace coroutines
with threads.

Paolo