aboutsummaryrefslogtreecommitdiff
path: root/hw
diff options
context:
space:
mode:
authorMarkus Armbruster <armbru@redhat.com>2010-07-27 14:02:01 +0200
committerKevin Wolf <kwolf@redhat.com>2010-08-03 15:57:22 +0200
commit4be9762adb0947a353e6efef2fed354f69218bfb (patch)
tree683126c17e372e298f686ed9aa9f53de86f5438b /hw
parent336c1c12551ff0a6e1a2af226d6cbdbadd2e02b5 (diff)
block: Change bdrv_eject() not to drop the image
bdrv_eject() gets called when a device model opens or closes the tray. If the block driver implements method bdrv_eject(), that method gets called. Drivers host_cdrom implements it, and it opens and closes the physical tray, and nothing else. When a device model opens, then closes the tray, media changes only if the user actively changes the physical media while the tray is open. This is matches how physical hardware behaves. If the block driver doesn't implement method bdrv_eject(), we do something quite different: opening the tray severs the connection to the image by calling bdrv_close(), and closing the tray does nothing. When the device model opens, then closes the tray, media is gone, unless the user actively inserts another one while the tray is open, with a suitable change command in the monitor. This isn't how physical hardware behaves. Rather inconvenient when programs "helpfully" eject media to give you a chance to change it. The way bdrv_eject() behaves here turns that chance into a must, which is not what these programs or their users expect. Change the default action not to call bdrv_close(). Instead, note the tray status in new BlockDriverState member tray_open. Use it in bdrv_is_inserted(). Arguably, the device models should keep track of tray status themselves. But this is less invasive. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'hw')
0 files changed, 0 insertions, 0 deletions