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.