qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_ME


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED
Date: Fri, 10 Feb 2012 21:47:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0

On 02/10/2012 08:39 PM, Paolo Bonzini wrote:

 1. added commands blockdev-tray-open, blockdev-tray-close,
blockdev-medium-insert,
    blockdev-medium-remove

I think this slightly overengineering.  eject and change work well
enough, we do not need blockdev-medium-insert and blockdev-medium-remove
(yet).  Of course there can be a new API, just nothing user-visible.

 2. added the events: BLOCK_TRAY_OPEN, BLOCK_TRAY_CLOSE,
BLOCK_MEDIUM_INSERTED
    BLOCK_MEDIUM_REMOVED, which would be emitted when the relating
command is issued
    (maybe the events could just be BLOCK_TRAY_CHANGED &
BLOCK_MEDIUM_CHANGED)

Or even just one event with two boolean arguments.

Looks slightly less clean, but it has an advantage: a guest that sends
"eject" can wait for an event and will know whether the eject command
was really executed (tray = open, medium = none) or just an eject
request was obeyed by the guest (tray = open, medium = present).

Now, maybe the guest eject could also emit BLOCK_TRAY_OPEN &
BLOCK_TRAY_CLOSE. Then
I think this is a complete solution.

Yes.

Hmm... I don't know...

The more I think about it, the more I like Luiz's original proposal of only signaling guest-initiated ejects. I won't hold up any other patch that works, but I cannot think of something that is as easily usable by management in a non-racy way.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]