Stefan Hajnoczi <stefa...@gmail.com> 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