Re: Configuring onboard devices

[Markus Armbruster <armbru@redhat.com>]

Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:

> 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.

I'm not familiar with this machine.  You make me suspect the serial
thingy is a component of a larger device.

Properly modelled, a composite device has its components as children.
These appear below their parent in the QOM composition tree.

Example: a "serial-isa" device has a "serial" component.  When the
former is at /machine/unattached/device[28]/, the latter is at
/machine/unattached/device[28]/serial/.

I guess that's what you want for macio's serial port.

Counter-example: a "isa-super-io" device has compoenents of type
"isa-parallel", "isa-serial", "isa-fdc", "i8042", "isa-ide".
Nevertheless, these appear next to their parent in /machine/unattached/.
I'm still too much of a QOM ignoramus to explain why that's so.  Paolo,
can you?

> 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.

Paolo, could link properties achieve that?

Mark, I guess you want the alias / link from builtin/nic0 to the actual
place to simplify configuration: the user then needs to know less about
the board.  Correct?