Re: [Qemu-devel] [RFC PATCH] qdev: add -pcidevice command line option.

[Markus Armbruster <armbru@redhat.com>]

Gerd Hoffmann <kraxel@redhat.com> writes:

> Ok, lets start to collect some low-hanging fruit we can get from the
> qdev bits even at the current early state.
>
> ==> stop adding cmd line switches for each and every device <==
> ==>        do funky stuff you could not do before           <==
>
> Here is a patch adding a generic -pcidevice command line switch.  Works
> only for qdev-converted devices.  Works (for now) only for devices which
> don't need configuration (i.e. nics don't work or maybe use vlan0
> unconditionally).  Most useful with my qdev patch queue applied.
>
> Examples:
>
>   -pcidevice ES1370,addr=42        (replaces -audio es1370).
>   -pcidevice virtio-balloon-pci    (replaces -balloon).
>   -pcidevice lsi53c895a,addr=23    (add scsi adapter in specified slot).
>   -pcidevice "PIIX3 USB-UHCI"      (add second usb bus).
>
> Comments?
>
> Note that we proably need a bunch of additional cleanups like killing
> the -balloon switch and maybe some safety bells to stop users from doing
> crazy stuff like adding a second acpi adapter.  Might be the scsi
> example doesn't actually work with disks due to initialization order
> issues.  None of this is in this RfC patch yet.
>
> Cc: Markus Armbruster <armbru@redhat.com>

Why limit this to PCI devices?  The device name indirectly specifies the
bus type.  Parameter addr then specifies bus instance and device address
on the bus, in a bus-specific syntax.  Of course, it's perfectly fine to
implement only PCI initially, but I'd rather not encode that restriction
in the option name :)

To extend this to devices that need configuration: what about
interpreting additional parameters as qdev properties?  Oh, there's a
TODO in pci_device_add() that suggests exactly that.