Like qdev_init(), but terminate program via hw_error() instead of
returning an error value.
Use it instead of qdev_init() where terminating the program on failure
is okay, either because it's during machine construction, or because
we know that failure can't happen.
Because relying in the latter is somewhat unclean, and the former is
not always obvious, it would be nice to go back to qdev_init() in the
not-so-obvious cases, only with proper error handling. I'm leaving
that for another day, because it involves making sure that error
values are properly checked by all callers.
Patchworks-ID: 35168
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Problem: Our file sys-queue.h is a copy of the BSD file, but there are
some additions and it's not entirely compatible. Because of that, there have
been conflicts with system headers on BSD systems. Some hacks have been
introduced in the commits 15cc923584,
f40d753718,
96555a96d7 and
3990d09adf but the fixes were fragile.
Solution: Avoid the conflict entirely by renaming the functions and the
file. Revert the previous hacks.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Sorry folks, but it has to be. One more of these invasive qdev patches.
We have a serious design bug in the qdev interface: device init
callbacks can't signal failure because the init() callback has no
return value. This patch fixes it.
We have already one case in-tree where this is needed:
Try -device virtio-blk-pci (without drive= specified) and watch qemu
segfault. This patch fixes it.
With usb+scsi being converted to qdev we'll get more devices where the
init callback can fail for various reasons.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch is a major overhaul of the device properties. The properties
are saved directly in the device state struct now, the linked list of
property values is gone.
Advantages:
* We don't have to maintain the list with the property values.
* The value in the property list and the value actually used by
the device can't go out of sync any more (used to happen for
the pci.devfn == -1 case) because there is only one place where
the value is stored.
* A record describing the property is required now, you can't set
random properties any more.
There are bus-specific and device-specific properties. The former
should be used for properties common to all bus drivers. Typical
use case is bus addressing, i.e. pci.devfn and i2c.address.
Properties have a PropertyInfo struct attached with name, size and
function pointers to parse and print properties. A few common property
types have PropertyInfos defined in qdev-properties.c. Drivers are free
to implement their own very special property parsers if needed.
Properties can have default values. If unset they are zero-filled.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
BusInfo is filled with name and size (pretty much like I did for
DeviceInfo as well). There is also a function pointer to print
bus-specific device information to the monitor. sysbus is hooked
up there, I've also added a print function for PCI.
Device creation is slightly modified as well: The device type search
loop now also checks the bus type while scanning the list instead of
complaining thereafter in case of a mismatch. This effectively gives
each bus a private namespace for device names.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Paul Brook <paul@codesourcery.com>
Rationale: move device information from code to data structures.
v2: Adapt the drivers missed in the first version.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Implement and use a common device bus state. The main side-effect is
that creating a bus and attaching it to a parent device are no longer
separate operations. For legacy code we allow a NULL parent, but that
should go away eventually.
Also tweak creation code to veriry theat a device in on the right bus.
Signed-off-by: Paul Brook <paul@codesourcery.com>
