af9e40aa8f
Drives defined with if!=none are for board initialization to wire up.
Board code calls drive_get() or similar to find them, and creates
devices with their qdev drive properties set accordingly.
Except a few devices go on a fishing expedition for a suitable backend
instead of exposing a drive property for board code to set: they call
driver_get() or drive_get_next() in their realize() or init() method
to implicitly connect to the "next" backend with a certain interface
type.
Picking up backends that way works when the devices are created by
board code. But it's inappropriate for -device or device_add. Not
only is this inconsistent with how the other block device models work
(they connect to a backend explicitly identified by a "drive"
property), it breaks when the "next" backend has been picked up by the
board already.
Example:
$ qemu-system-arm -S -M connex -pflash flash.img -device ssi-sd
Aborted (core dumped)
Mark them with suitable FIXME comments.
Cc: Andrzej Zaborowski <balrogg@gmail.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: "Andreas Färber" <andreas.faerber@web.de>
Cc: Michael Walle <michael@walle.cc>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
|
||
|---|---|---|
| .. | ||
| dataplane | ||
| Makefile.objs | ||
| block.c | ||
| cdrom.c | ||
| ecc.c | ||
| fdc.c | ||
| hd-geometry.c | ||
| m25p80.c | ||
| nand.c | ||
| nvme.c | ||
| nvme.h | ||
| onenand.c | ||
| pflash_cfi01.c | ||
| pflash_cfi02.c | ||
| tc58128.c | ||
| virtio-blk.c | ||
| xen_blkif.h | ||
| xen_disk.c | ||