[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
>>  hotplug disk
>>  -ENOSPC on disk
>>
>> It's true that events don't correlate directly to commands, but they 
>> do correlate to the state of the system and that is affected by 
>> commands.
>
> events are time stamped.  In non-human mode, I think command responses 
> should be time stamped too so that a management tool knows when the 
> event was generated and can correlate the system state to the 
> particular event.

Timestamping doesn't help since the command could have been delayed in 
the monitor socket.

Further, we're now so deep down the complexity spiral that it has now 
become the most complicated piece of code in the entire system.  Surely 
the best way to synchronize events is to keep them on one timeline?

>>>>   Sure, we'll need to make sure notifications don't mix with 
>>>> command responses, and that all commands are acked (the (qemu) 
>>>> prompt serves that purpose now), but it seems to me do be a lot 
>>>> easier for the management end.
>>>
>>> FWIW, you can have asynchronous completion of monitor commands.  See 
>>> migration as an example.  The (qemu) prompt is the ack that the 
>>> command is finished.  You can only have one async command per 
>>> monitor session which is why you need multiple monitors.
>>
>> Migration has the -d switch to be truly async (not to wait).  We need 
>> an async notifier to tell us migration has finished or failed.
>
> Multiplexing multiple monitor sessions AFAICT is going to require a 
> non-human mode.  But it's totally orthogonal to this patch set.  You 
> could implement it today if you wanted.

I don't want multiplexed monitor sessions, at all.  I want async 
notifications added to a single monitor session.  That too could be 
implemented today (as simple as a term_printf("notification: ...\n");

>>>
>>> If we had a non-human monitor mode, I think it would be fine to have 
>>> many monitors multiplexed over a single channel.  The internal 
>>> monitor abstraction doesn't change.
>>
>> I don't understand why we need to multiplex many monitors over one 
>> channel.  Let's keep one monitor, but with the ability to send 
>> notifications to the other end.
>
> I don't understand how you think it would be implemented.  Each 
> command is going to have a unique 'Monitor *' associated with it.  How 
> that ends up being displayed to the user/management tool is 
> irrelevant.  Right now, you can only have one 'Monitor *' active on a 
> single "channel" at a time.  This is mostly a matter of output 
> format.  I don't see how we can keep the monitor output consistent and 
> compatible as it stands today and still support multiple 'Monitor *'s 
> active in a single channel.
>

Again, I have no interest in multiple Monitor *s on the same channel.  
One is quite sufficient.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.