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 16:49:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Stefan Hajnoczi <address@hidden> writes:

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

Yup.

We've had discussions where couldn't even agree whether a specific block
driver is a format or a protocol or something else entirely.  This is
because the code doesn't really make distinctions.

> Fields like "backing_file" *should* be in generic code, not duplicated
> in each Format.

Debatable.

>                  But BlockDriverState is too generic since it also
> encompasses Protocols and Listeners.
>
> 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.
>
> As has been pointed out, "Listener" suggests a passive role.  Perhaps
> BlockFilter, BlockProcessor, or BlockModule is a better name.

BlockFilter sounds good to me.

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

Wouldn't that be nice.



reply via email to

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