Am 16.02.2012 19:30, schrieb Markus Armbruster: > Let's figure out how this stuff really works. > > 1. Guest load/eject > > Guest commands load or eject. Device model updates its state of virtual > tray (e.g. IDEState member tray_open) unless locked, then calls > bdrv_eject(). > > bdrv_eject() is a no-op except for pass-through backends such as > host_cdrom. > > Note: device models call bdrv_eject() whether the state changed or not. > The only use for that I can see is syncing a wayward physical tray to > the virtual one. Shouldn't be necessary with Paolo's recent work, > should it?
The one case that I'm unsure about is migration. I thought we sync the physical tray with the virtual one then (or at least we discussed it), but I don't really know what we do today, or even what the right thing to do is in some cases. > I figure Luiz's patch works. But maybe it could be simplified some by > replacing bdrv_dev_change_media_cb() by a "open/close tray" callback > that returns whether it moved. bdrv_dev_change_media_cb() would then > simply open the tray, emit event if it moved, close the tray, emit event > if it moved. Yes, I had the same impression after reading the first few paragraphs of your analysis (which looks right to me). Kevin
