[Qemu-devel] Confused by QOM: /machine/unattached/device[5]/dr-connector[255]/fdt

[Markus Armbruster]

I ran into this:

    $ qemu-system-ppc64 -nodefaults -S -display none -monitor stdio -machine 
pseries-2.4
    QEMU 2.4.50 monitor - type 'help' for more information
    (qemu) qom-list /machine/unattached/device[5]/dr-connector[255]
    fdt (struct)
    entity-sense (uint32)
    name (string)
    connector_type (uint32)
    index (uint32)
    id (uint32)
    allocation-state (uint32)
    indicator-state (uint32)
    isolation-state (uint32)
    parent_bus (link<bus>)
    hotplugged (bool)
    hotpluggable (bool)
    realized (bool)
    type (string)
    (qemu) qom-list /machine/unattached/device[5]/dr-connector[255]/fdt
    Device '/machine/unattached/device[5]/dr-connector[255]/fdt' not found

According to the first qom-list, .../fdt exists.  According to the
second, it doesn't.

I messed around in GDB a bit, and found that the second qom-list's final
object_resolve_path_component() returns NULL like this:

    Breakpoint 5, object_resolve_path_component (parent=0x55555659f0f0, 
        part=0x5555564b0660 "fdt") at /home/armbru/work/qemu/qom/object.c:1492
    1492            if (prop == NULL) {
    (gdb) p prop
    $27 = (ObjectProperty *) 0x55555659faf0
    (gdb) n
    1496            if (prop->resolve) {
    (gdb) 
    1501        }
    (gdb) p prop->resolve
    $28 = (ObjectPropertyResolve *) 0x0

The "fdt" property exists, but its ->resolve() callback is null.

object_resolve_path_component()'s function comment:

 * Returns: The final component in the object's canonical path.  The canonical
 * path is the path within the composition tree starting from the root.

Doesn't sound like NULL means failure.

Its caller object_resolve_abs_path() then also returns NULL.  No
function comment.  Likewise, its caller object_resolve_path_type()
returns NULL.  Its function comment:

 * Returns: The matched object or NULL on path lookup failure.

Here, NULL definitely means failure, and a specific one: path lookup
failure.

Its caller qmp_qom_list() then fails, setting a "Device
'/machine/unattached/device[5]/dr-connector[255]/fdt' not found" error.

Does this work as intended?