The difference between `ObjectClass` and `Object` in qemu

Issue

I am learning qemu and qom recently. I am perplexed when I meet the conception of ObjectClass and Object. I already understand that ObjectClass stands for class while Object means instance of class. However, what I want to know is What kind of information should store in ObjectClass and what's going on in Object.

As far as I am concerned, like C++ or Java, Object just the same as what's define in Class and be used in real logic. In this case, Class seems like a template which produce Object the real be used.

In qemu, everything seems different. We define these two in two struct, and they have different properties, which leads to separation of Class and Object. Does it means I can use one ObjectClass to produce many Object that differ with each other? And secondly, why should I do this? Are there any advantages of this pattern? In detail, what's the role ObjectClass and Object plays in qemu respectively? And what about their relationship? If I want to design a new device, What should I do in initialization of MyObjectClass and MyObject?

What's more, I notice that qemu will initialize every ObjectClass by TypeImpl, which is initialized by TypeInfo defined by developer.

TypeInfo => ModuleEntry => TypeImpl => ObjectClass => Object

Of course they do different things. TypeInfo converts to ModuleEntry before main function is executed(__attribute__((constructor))), which contains initial functions of ObjectClass and Object. Why we need this mechanism? On the other words, what if we just create ObjectClass instead of create TypeImpl and create ObjectClass after that? Any advantages?

Solution

This is part of QEMU's object model (QOM), which is documented in the developer section of the documentation. You should read that, and also look through include/qom/object.h for more details of the object model.

In QOM, for any class there is one class struct -- for the base Object type the class struct is ObjectClass. There are then multiple objects created at runtime, each of which is a struct Object. This applies also for subtypes of Object, like DeviceState, whose class struct is DeviceClass. The class struct holds fields which are common to every instance of that object type, notably including the function pointers which are the equivalent of methods. The object struct holds all the fields which are per-instance. Because each Object contains a pointer to the corresponding ObjectClass, you can always get from a pointer to an instance of an object to its class information.

Because we're implementing an object-oriented model in C, we have to have everything be explicit -- in C++ and Java, because the object model is part of the language the compiler can sort out under the hood a lot of the things QOM has to manage manually with class structs and object structs and so on.

More generally, if your aim is "write a new device" I would recommend that you do not spend any time looking into the internals of the QOM implementation. Instead you should look at how other devices similar to yours are implemented and at what the patterns of code are that they use to declare and use a new device type.

Answered By - Peter Maydell