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