Re: [Qemu-devel] [PATCH v2 0/4] blockdev: Add blockdev-change-medium with read-only option

[Markus Armbruster <armbru@redhat.com>]

Max Reitz <mreitz@redhat.com> writes:

> The 'change' QMP and HMP command allows replacing the medium in drives
> which support this, e.g. floppy disk drives. For some drives, the medium
> carries information about whether it can be written to or not (again,
> floppy drives). Therefore, it should be possible to change the read-only
> state of block devices when changing the loaded medium.
>
> Following a suggestion from Eric, this series first introduces a
> 'blockdev-change-medium' QMP command which is intended to replace the
> 'change' command for block devices. Then, an optional additional
> 'read-only' parameter is added which allows chaning the read-only state
> in three ways:
>
> - 'retain': Just keep the status as it was before; this is the current
>   behavior and thus this will be the default.
> - 'ro': Force read-only access
> - 'rw': Force writable access
>
> Finally, that 'read-only' parameter is added to the HMP 'change'
> command. This series does not add a 'blockdev-change-medium' QMP command
> because 'change' being overloaded for VNC and block devices is not too
> bad for HMP (while it is for QMP).

Debatable, but let's hash out QMP before we worry about HMP.

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

Both the operator and the guest OS can load / eject.

Only the operator can remove / insert medium.

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?