On 30/04/2020 16:20, Markus Armbruster wrote:
>> Ah I see now, these aliases are for individual properties rather than
>> objects. What I
>> was trying to ask was if it were possible to have something like this:
>>
>> /machine (SS-5-machine)
>> /builtin
>> /nic0 -> link to "lance" device
>>
>> Here nic0 is an alias "published" by the maintainer of the SS-5 machine
>> which is
>> configured in the machine init() function using object_property_add_link()
>> or a
>> suitable wrapper. Users can then configure these builtin devices from the
>> command
>> line using your -machine nic0.netdev=my-netdev-id syntax or similar.
>
> Got it now, thanks!
>
>> Having the default devices under /builtin or other known QOM path would
>> enable
>> builtin devices to be easily enumerated programatically and/or from the
>> command line
>> as required.
>
> There are three standard containers under /machine/:
>
> * /machine/peripheral/
>
> Devices with a user-specified ID go here, as /machine/peripheral/ID.
> User-specified means -device or device_add.
>
> /machine/peripheral/ID is effectively a stable interface. It's just
> underdocumented (undocumented?).
>
> To be useful, the stuff below ID/ needed to be stable and documented,
> too.
>
> * /machine/peripheral-anon/
>
> Same, but user elected not to give an ID.
> /machine/peripheral-anon/device[N], where N counts up from zero in
> creation order.
>
> N is obviously not stable, but this is a problem of the user's making.
> If you want to refer to a device, give it an ID.
>
> * /machine/unattached/
>
> The orphanage. When a device has no parent when its realized, it gets
> put here, as /machine/unattached/device[N], where N counts up from
> zero in realization order.
>
> N is obviously not stable, and this time we can't blame the
> victim^Wuser. You can search for devices of a certain type.
> Sometimes that's good enough.
>
> All the onboard devices are here, and much more. We've fathered a lot
> of unloved red-headed children, it seems...
>
> Some of the "much more" is due to sloppy modelling, i.e. neglecting to
> set the proper parent.
>
> I figure we could put onboard devices in a nicer place, with nicer
> names. Need a convention for the place and the names, then make board
> code conform to it.
That's good, it seems that this is already fairly close to how it works for
-device
at the moment.
I don't think that it is possible to come up a single place for on-board
devices to
live directly though. Going back to one of my first examples: wiring up a
chardev to
a serial port on the macio device. To me it makes sense for that to exist in QOM
under /machine/pci-bus/mac-io/escc. In contrast an in-built NIC could live under
/machine/pci-bus/in-built/nic, and placing one or both of these devices directly
under /machine/foo doesn't feel intuitive.
AFAIK as per your ARM virt example I believe it is only possible to register an
alias
for a property rather than for an Object? The ultimate aim would be for
object_resolve_path("/machine/builtin/nic0") and
object_resolve_path("/machine/pci-bus/in-built/nic") to return the same Object,
and
for the aliases on built-in devices to be children of /machine/builtin to allow
easy
iteration and introspection.
ATB,
Mark.
