On 12/05/2014 06:47 AM, Max Reitz wrote: >> I'd like to make sure that new commands to control removable media get >> us closer to a sane set of such commands. Let's consider states and >> transitions. >> >> If we ignore the tray lock for a moment, we have: >> >> load >> tray open ---------------> tray closed >> empty <--------------- empty >> ^ | eject >> | | >> remove medium | | insert medium >> | | >> | v load >> tray open ---------------> tray closed >> full <--------------- full >> eject
By name, this command feels like it is just the remove/insert medium step, and unrelated to tray open/close steps. >> >> Both the operator and the guest OS can load / eject. >> >> Only the operator can remove / insert medium. Where change is a special case of remove and insert done together. >> >> A tray lock complicates things a bit. Each state above splits into a >> locked and unlocked state, with the obvious lock / unlock state >> transitions. Only the guest OS can lock / unlock. >> >> When the tray is locked and closed, operator eject merely notifies the >> guest OS (blk_dev_eject_request(blk, false)). >> >> In states tray closed / locked, there's an additional operation "eject >> forcefully". It notifies the guest OS (blk_dev_eject_request(blk, >> true)), and opens the tray. Whether unlocks it depends on the device. >> >> Like change, blockdev-change-medium conflates several basic operations. >> Is that what we want, or should we create something that lets us do >> basic operations? change lacks a force parameter, which means that it feels like something that can only be attempted when the tray is open. The fact that we (can) make it auto-open an (unlocked) tray under the hood may be okay for HMP, but should not be part of the QMP command. > > Good question. I don't think it will be bad in practice, though. If you > split up blockdev-change-medium or really only change the medium without > loading it, then the only advantage that you get is that you can > exchange media without loading them; I can't really think of a use case > for that, so in reality you'll always have blockdev-change-medium > followed immediately by blockdev-load-medium or blockdev-close-tray or > whatever. > > You could split it up even more of course, then you'd have the following > order for loading a medium: > (1) 'blockdev-open-tray', if not yet open > (2) 'blockdev-remove-medium', if not yet empty > (3) 'blockdev-insert-medium' I'm not sure if 2 and 3 need to be separate, or if they can be a single change-medium command. > (4) 'blockdev-close-tray But yes, I think we need separate QMP commands for tray movement as compared to medium changes, and that medium change should fail if the tray is closed. Higher level software can string together multiple QMP commands to give the user a single 'change' experience, as desired, but I don't think QMP should provide such a command, as it is harder to determine what state things are left in if it fails halfway through. > > I can't think of any time when you'd want to call insert-medium without > close-tray or without having called remove-medium before (well, if it's > empty, you don't have to, but well...). > > And 'eject' does blockdev-open-tray plus blockdev-remove-medium, so... > > Or better, let's collect use cases: Use cases are the HMP (or libvirt) side of things. If the use case can be accomplished by stringing together multiple well-defined QMP operations, instead of having an overloaded QMP command that does multiple steps, that's still okay for the user's point of view . > (1) Insert medium into empty drive and load it: Works with > 'blockdev-change-medium' Umm, I'm actually agreeing with Markus that we probably want to separate changing the medium from closing the tray; while for floppies, there is no tray, so changing a medium is all the more you need to do. > (2) Open drive, remove medium: Works with 'eject' What about 'open drive, but leave medium in place for next time drive is closed'. Does 'eject' do that (possibly via the addition of an optional boolean that says whether to leave the medium intact)? Also, floppy drives can be locked, but have no tray; do we have the right semantics for requesting an eject but waiting for the guest to comply by unlocking the drive? > (3) Open drive, remove medium, insert medium, close drive: Works with > 'blockdev-change-medium' Or rather, works with the high-level HMP 'change', and may be implemented via multiple QMP commands under the hood. > (4) Open drive, remove medium, close drive: Does not work with only > 'eject' and 'blockdev-change-medium', but I can't see a difference > between an open drive and a closed empty drive For floppies, there isn't a difference (no tray, so no medium is all the more distinction you get). But for cdroms, the guest knows if the tray is still open or closed (it doesn't know if the medium is present when the tray is open; the fact that qemu still tracks medium for an open tray is for convenience in closing the tray and still having the medium ready to use if it wasn't changed while the tray was open). > (5) Open drive, repeatedly change medium, close drive: Does not work > with 'blockdev-change-medium' because the guest will see all the media > you cycled through; but I don't consider this an important use case May not be important, and may not be something we expose through HMP, but I agree with Markus that it would be nice to let the QMP side allow this. > > So, of course it may be nice in principle to have broken it down to the > fundamental operations, but I don't see the practical implication. > > Hm, well, there is one. I remember someone complaining that 'eject' > sometimes removes the medium and sometimes doesn't. It did remove the > medium when qemu could immediately eject it; but it didn't if the drive > was locked, the guest was notified and then the guest opened the tray. > So that is a practical implication, because after calling > blockdev-open-tray, you'd be sure that the medium is still inserted. > > I personally don't have a strong opinion. Introducing more commands > would be work, but I guess I would have time for that now. Requiring multiple QMP commands to do a high-level HMP operation may feel like overkill, but in the long run the finer granularity will be worth it. I think that limiting 'blockdev-change-medium' to work only on unlocked floppy drives and only on open-tray cdrom drives, plus the additional glue to open/close the cdrom tray as necessary, will be worth the effort. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
