All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/4] blockdev: Add blockdev-change-medium with read-only option
Date: Fri, 05 Dec 2014 14:25:59 +0100	[thread overview]
Message-ID: <5481B267.2020706@redhat.com> (raw)
In-Reply-To: <5481AFA2.2040507@redhat.com>

On 2014-12-05 at 14:14, Eric Blake wrote:
> On 12/05/2014 03:08 AM, Max Reitz wrote:
>> 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
> s/chaning/changing/ (I first read it as chaining) - of course, typos in
> cover letters don't really matter in the long run :)
>
>> 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
> I assume you meant HMP in this line.

Yes, right.

>> because 'change' being overloaded for VNC and block devices is not too
>> bad for HMP (while it is for QMP).
> I agree with that approach.
>
>>
>> v2:
>> - basically completely rewritten
>> - Dropped 'auto' [Kevin and Markus]
>> - Introduced blockdev-change-medium [Eric]
>>
>> - Patch 1 introduces the new QMP command 'blockdev-change-medium'; there
>>    are (at least) two questionable design choices which I want to explain
>>    here:
>>    - The name is rather long; furthermore, the name 'change-blockdev' was
>>      already suggested by the existing code. I used such a long name
>>      because (1) there are no *-blockdev commands, but there are
>>      blockdev-* commands, so "blockdev" should be the prefix, not the
>>      suffix, and (2) "blockdev-change" could mean anything, so I wanted
>>      to be as clear as possible.
> That's actually a good explanation; I'm fine with the name you ended up
> with, even if it feels long.
>
>>    - The 'format' argument is optional; this is because by making it
>>      mandatory, it would have been difficult for the 'change' QMP and HMP
>>      commands to retain their 'format' argument optional as well (which
>>      we have to do thanks to compatibility)
> Yep, I can see that.  On the other hand, the other questionable feature
> of 'change' was that it required a filename, but then allowed "" as the
> filename that meant no new medium.

Hm, really?

HMP:

(qemu) change fdd ""
Could not open image: No such file or directory

QMP:

{'execute':'change','arguments':{'device':'fdd','target':''}}
{"timestamp": {"seconds": 1417785755, "microseconds": 519130}, "event": 
"DEVICE_TRAY_MOVED", "data": {"device": "fdd", "tray-open": true}}
{"error": {"class": "GenericError", "desc": "Could not open image: No 
such file or directory"}}

Technically, the medium is now empty, but that wasn't a successful 
execution.

> In patch 1/4, I wonder if we should
> make the new command a bit stricter, by having 'filename' be optional,
> and by forbidding "" as a filename (it's still a 1:1 mapping to the old
> semantics, and while it would require more HMP glue, it would feel a bit
> cleaner from the interface side).

If it was indeed possible somehow, I'd vote for disallowing empty file 
names for blockdev-change-medium and instead invoke 'eject' from the 
'change' commands (and point to 'eject' in the 'change' documentation).

Max

  reply	other threads:[~2014-12-05 13:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 10:08 [Qemu-devel] [PATCH v2 0/4] blockdev: Add blockdev-change-medium with read-only option Max Reitz
2014-12-05 10:08 ` [Qemu-devel] [PATCH v2 1/4] qmp: Introduce blockdev-change-medium Max Reitz
2014-12-05 13:10   ` Eric Blake
2014-12-05 13:18     ` Max Reitz
2014-12-05 13:25       ` Eric Blake
2014-12-05 10:08 ` [Qemu-devel] [PATCH v2 2/4] hmp: Use blockdev-change-medium for change command Max Reitz
2014-12-05 13:24   ` Eric Blake
2014-12-05 13:27     ` Max Reitz
2014-12-05 13:45       ` Eric Blake
2014-12-05 10:08 ` [Qemu-devel] [PATCH v2 3/4] blockdev: Add read-only option to blockdev-change-medium Max Reitz
2014-12-05 13:28   ` Eric Blake
2014-12-05 10:08 ` [Qemu-devel] [PATCH v2 4/4] hmp: Add read-only option to change command Max Reitz
2014-12-05 13:49   ` Eric Blake
2014-12-05 13:14 ` [Qemu-devel] [PATCH v2 0/4] blockdev: Add blockdev-change-medium with read-only option Eric Blake
2014-12-05 13:25   ` Max Reitz [this message]
2014-12-05 13:31 ` Markus Armbruster
2014-12-05 13:47   ` Max Reitz
2014-12-05 14:07     ` Eric Blake
2014-12-05 14:21       ` Max Reitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5481B267.2020706@redhat.com \
    --to=mreitz@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.