Re: Configuring onboard devices

[Mark Cave-Ayland]

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.