Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 14 5月, 2014 1 次提交
  3. 08 5月, 2014 3 次提交
  5. 18 4月, 2014 1 次提交
  7. 14 2月, 2014 1 次提交
  9. 25 12月, 2013 1 次提交
    • M
      hw: cannot_instantiate_with_device_add_yet due to pointer props · 1b111dc1
      由 Markus Armbruster 提交于 
      Pointer properties can be set only by code, not by device_add.  A
device with a pointer property can work with device_add only when the
property may remain null.

This is the case for property "interrupt_vector" of device
"etraxfs,pic".  Add a comment there.

Set cannot_instantiate_with_device_add_yet for the other devices with
pointer properties, with a comment explaining why.

Juha Riihimäki and Peter Maydell deserve my thanks for making "pointer
property must not remain null" blatantly obvious in the OMAP devices.

Only device "smbus-eeprom" is actually changed.  The others are all
sysbus devices, which get cannot_instantiate_with_device_add_yet set
in their abstract base's class init function.  Setting it again in
their class init function is technically redundant, but serves as
insurance for when sysbus devices become available with device_add,
and as documentation.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@gmail.com> (for ETRAX)
Signed-off-by: NAndreas Färber <afaerber@suse.de>
      1b111dc1
  11. 23 12月, 2013 2 次提交
    • M
      ich9: Document why cannot_instantiate_with_device_add_yet · bfa6dfd0
      由 Markus Armbruster 提交于 
      An ICH9 southbridge contains several PCI devices, some of them with
multiple functions.  We model each function as a separate qdev.  Two
of them need some special wiring set up in pc_q35_init() to work: the
LPC controller at 00:1f.0, and the SMBus controller at 00:1f.3.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
      bfa6dfd0
    • M
      qdev: Replace no_user by cannot_instantiate_with_device_add_yet · efec3dd6
      由 Markus Armbruster 提交于 
      In an ideal world, machines can be built by wiring devices together
with configuration, not code.  Unfortunately, that's not the world we
live in right now.  We still have quite a few devices that need to be
wired up by code.  If you try to device_add such a device, it'll fail
in sometimes mysterious ways.  If you're lucky, you get an
unmysterious immediate crash.

To protect users from such badness, DeviceClass member no_user used to
make device models unavailable with -device / device_add, but that
regressed in commit 18b6dade.  The device model is still omitted from
help, but is available anyway.

Attempts to fix the regression have been rejected with the argument
that the purpose of no_user isn't clear, and it's prone to misuse.

This commit clarifies no_user's purpose.  Anthony suggested to rename
it cannot_instantiate_with_device_add_yet_due_to_internal_bugs, which
I shorten somewhat to keep checkpatch happy.  While there, make it
bool.

Every use of cannot_instantiate_with_device_add_yet gets a FIXME
comment asking for rationale.  The next few commits will clean them
all up, either by providing a rationale, or by getting rid of the use.

With that done, the regression fix is hopefully acceptable.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
      efec3dd6
  13. 30 7月, 2013 4 次提交
  15. 29 7月, 2013 1 次提交
  17. 23 7月, 2013 1 次提交
  19. 10 7月, 2013 1 次提交
  21. 04 7月, 2013 2 次提交
  23. 07 6月, 2013 1 次提交
  25. 09 4月, 2013 4 次提交