Re: Configuring onboard devices

[Mark Cave-Ayland]

On 30/04/2020 15:11, Markus Armbruster wrote:

> Mark Cave-Ayland <address@hidden> writes:
> 
>> On 30/04/2020 11:03, Markus Armbruster wrote:
>>> Peter Maydell <address@hidden> writes:
>>>
>>>> On Thu, 30 Apr 2020 at 08:09, Markus Armbruster <address@hidden> wrote:
>>>>> Our means to configure onboard devices are weak.  We sidestepped this
>>>>> for isa-fdc by taking it off the board, and thus make -device work.
>>>>
>>>> This seems to be a general dynamic: the x86 pc machine works
>>>> via -device options (or is changed so it can work that way);
>>>> and then people propose dropping/deprecating/etc the config
>>>> options that work with onboard devices, without providing
>>>> clear solutions/instructions on how the command line needs
>>>> to change/etc for the mass of boards which are not the x86
>>>> pc machine and which do have a lot of onboard devices which
>>>> can't be handled via -device.
>>>>
>>>> So my gut reaction to the "we should deprecate -global"
>>>> suggestions in this thread was a bit "here we go again"...
>>>> What works for x86 or even "what is sufficient for libvirt"
>>>> doesn't necessarily cover all the cases.
>>>
>>> Such shortsighted proposals have been made, but don't think it's what
>>> we're doing here.
>>>
>>> You're 100% right in that we do need to configure onboard devices.
>>> -global is a terrible way to do it, though: it applies to *all* devices
>>> of a kind.  What if the board has more than one?  What if the can add
>>> more?
>>>
>>> Taking onboard devices off the board can occasionally sidestep the
>>> issue.  For isa-fdc, we genuinely *wanted* to take the damn thing off,
>>> because all it did for most users was provide them with VENOM.  Not
>>> needing -global for it anymore was just a nice bonus.
>>>
>>> Taking onboard devices off just to reduce the device configuration
>>> problem to a solved one, namely -device, may be tempting (it was to me),
>>> but it's too intrusive to be practical at scale.
>>>
>>> Adding machine properties that alias onboard device properties is less
>>> intrusive.  The ones I added were still a lot of work.
>>>
>>> Configuring onboard devices via machine properties restricts property
>>> access to the ones we added to the machine.  This differs from pluggable
>>> devices, where users can access all properties.
>>>
>>> Any better ideas for letting users configure onboard devices?
>>
>> Is it possible to let machine owners add alias properties to the machine 
>> object
>> referencing in-built devices? I could then instantiate my on-board nic in 
>> the machine
>> init() function, and then use object_property_add_alias() to add a "nic0" 
>> alias on
>> the machine that can be used to wire it up to a netdev using the command 
>> line.
> 
> Have a look at hw/arm/virt.c's virt_flash_create(), from commit
> e0561e60f1 "hw/arm/virt: Support firmware configuration with -blockdev".
> It adds machine properties "pflash0" and "pflash1" as aliases for the
> onboard flash memory devices' property "drive".
> 
> Does this answer your question?

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.

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.


ATB,

Mark.