Anthony Liguori wrote:
Avi Kivity wrote:
> I'm sorry, I don't see why. It's just like a shell session.
>
> Compare with:
>
> Monitor 1:
> (qemu) notify enospace on
> (qemu) notify vnc-connect on
> (qemu) notify migration-completion on
> (qemu) migrate -d ...
> (qemu) migrate_cancel
> (qemu) migrate -d ...
>
>
> Monitor 2:
> (qemu) wait
> vnc connection ...
> (qemu) wait
> enospc on ide0-0
> (qemu) wait
> migration cancelled
> (qemu) wait
> notification: migration completed
>
> There is no way to tell by looking what has happened (well, in this
> case you can, but in the general case you cannot). You have to look
> at two separate interactive sessions (ctrl-alt-2 ctrl-alt-3
> ctrl-alt-3). You have to keep reissuing the wait command. Oh, and
> it's racy, so if you're interested in what really happens you have to
> issue info commands on session 1.
How is it less racy?
Suppose you have a command which changes the meaning of a notification.
If a notification arrives before the command completion, then it
happened before the command was executed. If it arrives after command
completion, then it happened after the command was executed.
Oh. If the command generates no output (like most), you can't tell when
it completes. I suppose we could have qemu print OK after completing a
command.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.