[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] multiprocess: move feature to meson_options.txt
From: |
Jag Raman |
Subject: |
Re: [PATCH] multiprocess: move feature to meson_options.txt |
Date: |
Thu, 25 Feb 2021 17:50:07 +0000 |
> On Feb 25, 2021, at 11:35 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> On Thu, Feb 25, 2021 at 01:15:53PM +0100, Paolo Bonzini wrote:
>> On 25/02/21 11:38, Philippe Mathieu-Daudé wrote:
>>> On 2/24/21 1:23 PM, Paolo Bonzini wrote:
>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>>> ---
>>>> configure | 12 ++++--------
>>>> meson.build | 9 +++++++--
>>>> meson_options.txt | 2 ++
>>>> 3 files changed, 13 insertions(+), 10 deletions(-)
>>> ...
>>>
>>>> @@ -2535,6 +2540,7 @@ endif
>>>> summary_info += {'target list': ' '.join(target_dirs)}
>>>> if have_system
>>>> summary_info += {'default devices': get_option('default_devices')}
>>>> + summary_info += {'Multiprocess QEMU': multiprocess_allowed}
>>>
>>> Since you are changing this, it is a good opportunity to find a
>>> better description to this feature (similarly how we recently clarified
>>> the TCI description).
>>>
>>> The current description is confusing with multiprocessing (which is
>>> by default on QEMU and every developer want to exploit that).
>>>
>>> So the main multiprocess code resides in hw/remote/mpqemu*.
>>>
>>> I have the impression "monolithic application" is common in
>>> software engineering. What about "polylithic QEMU"?
>>>
>>> Stefan once described it as "out of (main) process device emulation".
>>
>> Out of process emulation?
>
> When Multiprocess QEMU switches to the vfio-user protocol the feature
> could be renamed to "vfio-user device backends".
I personally don’t have any preference for the name.
Like Stefan pointed out, this would be merged with the
vfio-user model for emulating devices in a separate
process. We could probably rename this during that change.
Thank you very much!
—
Jag
>
> Stefan