[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 :|
>
- Re: Redesign of QEMU startup & initial configuration, (continued)
Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/10
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/10
- Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/13
- Meeting today?,
Mark Burton <=
- Re: Meeting today?, Markus Armbruster, 2021/12/14
- Re: Meeting today?, Mark Burton, 2021/12/14
- Re: Meeting today?, Daniel P . Berrangé, 2021/12/14
- Re: Meeting today?, Markus Armbruster, 2021/12/14
Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/15
Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/15
Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/14
Re: Redesign of QEMU startup & initial configuration, Mark Burton, 2021/12/14
Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/14
Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/15