qemu-devel
[Top][All Lists]
Advanced

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

Meeting today?


From: Mark Burton
Subject: Meeting today?
Date: Tue, 14 Dec 2021 08:09:42 +0100

I realise it’s very short notice, but what about having a discussion today at 
15:00 ?
Cheers
Mark.


> On 13 Dec 2021, at 19:53, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> On Mon, Dec 13, 2021 at 07:37:49PM +0100, Paolo Bonzini wrote:
>> On 12/13/21 19:07, Daniel P. Berrangé wrote:
>>>   - /usr/bin/qemu (or /usr/bin/qemu-vm) - for a high level binary that
>>>     targets humans and uses a templating system to expose a friendly
>>>     simple config, that internally invokes whichever target specific
>>>     /usr/bin/qemu-buildvm-$TARGET is implied, plus any other vhost-user
>>>     backends, or whatever other helper processes it needs
>> 
>> Adding vhost-user backends and helper processes means one of two things:
>> either you are not going to support hotplug, or you are going to redo
>> libvirtd with a QMP-based RPC.
> 
> I can't say I thought about the helper process idea too much. I was not
> trying to imply anything beyond the fact that I think at the high level
> human users should only have interact with a single QEMU binary, not
> per-target binaries, and also not worry about helper binaries if they
> happen to be used as impl details.
> 
> If it were possible to keep auto-spawning of helpers at the high level
> that feels cleaner, so that the low level only has to worry about a
> single way of doing things. If that is too hard for hotplug though,
> so be it, leave auto-spawning in the low level.
> 
> Any high level thing would need a monitor of some kind since there'll
> always be a need for humans to interrogate the QEMU to some degree. If
> we're trying to keep the monitor high level though, we'd want something
> closer to HMP. Perhaps again have an HMP that's based around a template
> engine that spits out QMP commands, and can extract bits of the reply
> for pretty printing, so again we're not writing C code for each new
> command that we care to support, just simple template snippets, that
> users can again customize if needed.
> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 




reply via email to

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