1.. _qom: 2 3=========================== 4The QEMU Object Model (QOM) 5=========================== 6 7.. highlight:: c 8 9The QEMU Object Model provides a framework for registering user creatable 10types and instantiating objects from those types. QOM provides the following 11features: 12 13- System for dynamically registering types 14- Support for single-inheritance of types 15- Multiple inheritance of stateless interfaces 16- Mapping internal members to publicly exposed properties 17 18The root object class is TYPE_OBJECT which provides for the basic 19object methods. 20 21The QOM tree 22============ 23 24The QOM tree is a composition tree which represents all of the objects 25that make up a QEMU "machine". You can view this tree by running 26``info qom-tree`` in the :ref:`QEMU monitor`. It will contain both 27objects created by the machine itself as well those created due to 28user configuration. 29 30Creating a QOM class 31==================== 32 33A simple minimal device implementation may look something like below: 34 35.. code-block:: c 36 :caption: Creating a minimal type 37 38 #include "qdev.h" 39 40 #define TYPE_MY_DEVICE "my-device" 41 42 // No new virtual functions: we can reuse the typedef for the 43 // superclass. 44 typedef DeviceClass MyDeviceClass; 45 typedef struct MyDevice 46 { 47 DeviceState parent_obj; 48 49 int reg0, reg1, reg2; 50 } MyDevice; 51 52 static const TypeInfo my_device_info = { 53 .name = TYPE_MY_DEVICE, 54 .parent = TYPE_DEVICE, 55 .instance_size = sizeof(MyDevice), 56 }; 57 58 static void my_device_register_types(void) 59 { 60 type_register_static(&my_device_info); 61 } 62 63 type_init(my_device_register_types) 64 65In the above example, we create a simple type that is described by #TypeInfo. 66#TypeInfo describes information about the type including what it inherits 67from, the instance and class size, and constructor/destructor hooks. 68 69The TYPE_DEVICE class is the parent class for all modern devices 70implemented in QEMU and adds some specific methods to handle QEMU 71device model. This includes managing the lifetime of devices from 72creation through to when they become visible to the guest and 73eventually unrealized. 74 75Alternatively several static types could be registered using helper macro 76DEFINE_TYPES() 77 78.. code-block:: c 79 80 static const TypeInfo device_types_info[] = { 81 { 82 .name = TYPE_MY_DEVICE_A, 83 .parent = TYPE_DEVICE, 84 .instance_size = sizeof(MyDeviceA), 85 }, 86 { 87 .name = TYPE_MY_DEVICE_B, 88 .parent = TYPE_DEVICE, 89 .instance_size = sizeof(MyDeviceB), 90 }, 91 }; 92 93 DEFINE_TYPES(device_types_info) 94 95Every type has an #ObjectClass associated with it. #ObjectClass derivatives 96are instantiated dynamically but there is only ever one instance for any 97given type. The #ObjectClass typically holds a table of function pointers 98for the virtual methods implemented by this type. 99 100Using object_new(), a new #Object derivative will be instantiated. You can 101cast an #Object to a subclass (or base-class) type using 102object_dynamic_cast(). You typically want to define macro wrappers around 103OBJECT_CHECK() and OBJECT_CLASS_CHECK() to make it easier to convert to a 104specific type: 105 106.. code-block:: c 107 :caption: Typecasting macros 108 109 #define MY_DEVICE_GET_CLASS(obj) \ 110 OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE) 111 #define MY_DEVICE_CLASS(klass) \ 112 OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE) 113 #define MY_DEVICE(obj) \ 114 OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE) 115 116In case the ObjectClass implementation can be built as module a 117module_obj() line must be added to make sure qemu loads the module 118when the object is needed. 119 120.. code-block:: c 121 122 module_obj(TYPE_MY_DEVICE); 123 124Class Initialization 125-------------------- 126 127Before an object is initialized, the class for the object must be 128initialized. There is only one class object for all instance objects 129that is created lazily. 130 131Classes are initialized by first initializing any parent classes (if 132necessary). After the parent class object has initialized, it will be 133copied into the current class object and any additional storage in the 134class object is zero filled. 135 136The effect of this is that classes automatically inherit any virtual 137function pointers that the parent class has already initialized. All 138other fields will be zero filled. 139 140Once all of the parent classes have been initialized, #TypeInfo::class_init 141is called to let the class being instantiated provide default initialize for 142its virtual functions. Here is how the above example might be modified 143to introduce an overridden virtual function: 144 145.. code-block:: c 146 :caption: Overriding a virtual function 147 148 #include "qdev.h" 149 150 void my_device_class_init(ObjectClass *klass, void *class_data) 151 { 152 DeviceClass *dc = DEVICE_CLASS(klass); 153 dc->reset = my_device_reset; 154 } 155 156 static const TypeInfo my_device_info = { 157 .name = TYPE_MY_DEVICE, 158 .parent = TYPE_DEVICE, 159 .instance_size = sizeof(MyDevice), 160 .class_init = my_device_class_init, 161 }; 162 163Introducing new virtual methods requires a class to define its own 164struct and to add a .class_size member to the #TypeInfo. Each method 165will also have a wrapper function to call it easily: 166 167.. code-block:: c 168 :caption: Defining an abstract class 169 170 #include "qdev.h" 171 172 typedef struct MyDeviceClass 173 { 174 DeviceClass parent_class; 175 176 void (*frobnicate) (MyDevice *obj); 177 } MyDeviceClass; 178 179 static const TypeInfo my_device_info = { 180 .name = TYPE_MY_DEVICE, 181 .parent = TYPE_DEVICE, 182 .instance_size = sizeof(MyDevice), 183 .abstract = true, // or set a default in my_device_class_init 184 .class_size = sizeof(MyDeviceClass), 185 }; 186 187 void my_device_frobnicate(MyDevice *obj) 188 { 189 MyDeviceClass *klass = MY_DEVICE_GET_CLASS(obj); 190 191 klass->frobnicate(obj); 192 } 193 194Interfaces 195---------- 196 197Interfaces allow a limited form of multiple inheritance. Instances are 198similar to normal types except for the fact that are only defined by 199their classes and never carry any state. As a consequence, a pointer to 200an interface instance should always be of incomplete type in order to be 201sure it cannot be dereferenced. That is, you should define the 202'typedef struct SomethingIf SomethingIf' so that you can pass around 203``SomethingIf *si`` arguments, but not define a ``struct SomethingIf { ... }``. 204The only things you can validly do with a ``SomethingIf *`` are to pass it as 205an argument to a method on its corresponding SomethingIfClass, or to 206dynamically cast it to an object that implements the interface. 207 208Methods 209------- 210 211A *method* is a function within the namespace scope of 212a class. It usually operates on the object instance by passing it as a 213strongly-typed first argument. 214If it does not operate on an object instance, it is dubbed 215*class method*. 216 217Methods cannot be overloaded. That is, the #ObjectClass and method name 218uniquely identity the function to be called; the signature does not vary 219except for trailing varargs. 220 221Methods are always *virtual*. Overriding a method in 222#TypeInfo.class_init of a subclass leads to any user of the class obtained 223via OBJECT_GET_CLASS() accessing the overridden function. 224The original function is not automatically invoked. It is the responsibility 225of the overriding class to determine whether and when to invoke the method 226being overridden. 227 228To invoke the method being overridden, the preferred solution is to store 229the original value in the overriding class before overriding the method. 230This corresponds to ``{super,base}.method(...)`` in Java and C# 231respectively; this frees the overriding class from hardcoding its parent 232class, which someone might choose to change at some point. 233 234.. code-block:: c 235 :caption: Overriding a virtual method 236 237 typedef struct MyState MyState; 238 239 typedef void (*MyDoSomething)(MyState *obj); 240 241 typedef struct MyClass { 242 ObjectClass parent_class; 243 244 MyDoSomething do_something; 245 } MyClass; 246 247 static void my_do_something(MyState *obj) 248 { 249 // do something 250 } 251 252 static void my_class_init(ObjectClass *oc, void *data) 253 { 254 MyClass *mc = MY_CLASS(oc); 255 256 mc->do_something = my_do_something; 257 } 258 259 static const TypeInfo my_type_info = { 260 .name = TYPE_MY, 261 .parent = TYPE_OBJECT, 262 .instance_size = sizeof(MyState), 263 .class_size = sizeof(MyClass), 264 .class_init = my_class_init, 265 }; 266 267 typedef struct DerivedClass { 268 MyClass parent_class; 269 270 MyDoSomething parent_do_something; 271 } DerivedClass; 272 273 static void derived_do_something(MyState *obj) 274 { 275 DerivedClass *dc = DERIVED_GET_CLASS(obj); 276 277 // do something here 278 dc->parent_do_something(obj); 279 // do something else here 280 } 281 282 static void derived_class_init(ObjectClass *oc, void *data) 283 { 284 MyClass *mc = MY_CLASS(oc); 285 DerivedClass *dc = DERIVED_CLASS(oc); 286 287 dc->parent_do_something = mc->do_something; 288 mc->do_something = derived_do_something; 289 } 290 291 static const TypeInfo derived_type_info = { 292 .name = TYPE_DERIVED, 293 .parent = TYPE_MY, 294 .class_size = sizeof(DerivedClass), 295 .class_init = derived_class_init, 296 }; 297 298Alternatively, object_class_by_name() can be used to obtain the class and 299its non-overridden methods for a specific type. This would correspond to 300``MyClass::method(...)`` in C++. 301 302One example of such methods is ``DeviceClass.reset``. More examples 303can be found at :ref:`device-life-cycle`. 304 305Standard type declaration and definition macros 306=============================================== 307 308A lot of the code outlined above follows a standard pattern and naming 309convention. To reduce the amount of boilerplate code that needs to be 310written for a new type there are two sets of macros to generate the 311common parts in a standard format. 312 313A type is declared using the OBJECT_DECLARE macro family. In types 314which do not require any virtual functions in the class, the 315OBJECT_DECLARE_SIMPLE_TYPE macro is suitable, and is commonly placed 316in the header file: 317 318.. code-block:: c 319 :caption: Declaring a simple type 320 321 OBJECT_DECLARE_SIMPLE_TYPE(MyDevice, MY_DEVICE) 322 323This is equivalent to the following: 324 325.. code-block:: c 326 :caption: Expansion from declaring a simple type 327 328 typedef struct MyDevice MyDevice; 329 typedef struct MyDeviceClass MyDeviceClass; 330 331 G_DEFINE_AUTOPTR_CLEANUP_FUNC(MyDeviceClass, object_unref) 332 333 #define MY_DEVICE_GET_CLASS(void *obj) \ 334 OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE) 335 #define MY_DEVICE_CLASS(void *klass) \ 336 OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE) 337 #define MY_DEVICE(void *obj) 338 OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE) 339 340 struct MyDeviceClass { 341 DeviceClass parent_class; 342 }; 343 344The 'struct MyDevice' needs to be declared separately. 345If the type requires virtual functions to be declared in the class 346struct, then the alternative OBJECT_DECLARE_TYPE() macro can be 347used. This does the same as OBJECT_DECLARE_SIMPLE_TYPE(), but without 348the 'struct MyDeviceClass' definition. 349 350To implement the type, the OBJECT_DEFINE macro family is available. 351In the simple case the OBJECT_DEFINE_TYPE macro is suitable: 352 353.. code-block:: c 354 :caption: Defining a simple type 355 356 OBJECT_DEFINE_TYPE(MyDevice, my_device, MY_DEVICE, DEVICE) 357 358This is equivalent to the following: 359 360.. code-block:: c 361 :caption: Expansion from defining a simple type 362 363 static void my_device_finalize(Object *obj); 364 static void my_device_class_init(ObjectClass *oc, void *data); 365 static void my_device_init(Object *obj); 366 367 static const TypeInfo my_device_info = { 368 .parent = TYPE_DEVICE, 369 .name = TYPE_MY_DEVICE, 370 .instance_size = sizeof(MyDevice), 371 .instance_init = my_device_init, 372 .instance_finalize = my_device_finalize, 373 .class_size = sizeof(MyDeviceClass), 374 .class_init = my_device_class_init, 375 }; 376 377 static void 378 my_device_register_types(void) 379 { 380 type_register_static(&my_device_info); 381 } 382 type_init(my_device_register_types); 383 384This is sufficient to get the type registered with the type 385system, and the three standard methods now need to be implemented 386along with any other logic required for the type. 387 388If the type needs to implement one or more interfaces, then the 389OBJECT_DEFINE_TYPE_WITH_INTERFACES() macro can be used instead. 390This accepts an array of interface type names. 391 392.. code-block:: c 393 :caption: Defining a simple type implementing interfaces 394 395 OBJECT_DEFINE_TYPE_WITH_INTERFACES(MyDevice, my_device, 396 MY_DEVICE, DEVICE, 397 { TYPE_USER_CREATABLE }, 398 { NULL }) 399 400If the type is not intended to be instantiated, then the 401OBJECT_DEFINE_ABSTRACT_TYPE() macro can be used instead: 402 403.. code-block:: c 404 :caption: Defining a simple abstract type 405 406 OBJECT_DEFINE_ABSTRACT_TYPE(MyDevice, my_device, 407 MY_DEVICE, DEVICE) 408 409.. _device-life-cycle: 410 411Device Life-cycle 412================= 413 414As class initialisation cannot fail devices have an two additional 415methods to handle the creation of dynamic devices. The ``realize`` 416function is called with ``Error **`` pointer which should be set if 417the device cannot complete its setup. Otherwise on successful 418completion of the ``realize`` method the device object is added to the 419QOM tree and made visible to the guest. 420 421The reverse function is ``unrealize`` and should be were clean-up 422code lives to tidy up after the system is done with the device. 423 424All devices can be instantiated by C code, however only some can 425created dynamically via the command line or monitor. 426 427Likewise only some can be unplugged after creation and need an 428explicit ``unrealize`` implementation. This is determined by the 429``user_creatable`` variable in the root ``DeviceClass`` structure. 430Devices can only be unplugged if their ``parent_bus`` has a registered 431``HotplugHandler``. 432 433API Reference 434============= 435 436See the :ref:`QOM API<qom-api>` and :ref:`QDEV API<qdev-api>` 437documents for the complete API description. 438