On 30/04/2020 15:11, Markus Armbruster wrote: > Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> writes: > >> On 30/04/2020 11:03, Markus Armbruster wrote: >>> Peter Maydell <peter.mayd...@linaro.org> writes: >>> >>>> On Thu, 30 Apr 2020 at 08:09, Markus Armbruster <arm...@redhat.com> 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.