[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs su
Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
Wed, 02 Mar 2011 07:13:00 -0600
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:184.108.40.206) Gecko/20101207 Thunderbird/3.1.7
On 03/02/2011 04:19 AM, Jes Sorensen wrote:
On 02/28/11 18:44, Anthony Liguori wrote:
On Feb 28, 2011 10:44 AM, "Jes Sorensen"<address@hidden> wrote:
Separating host-side virtagent and other tasks from core QEMU
To improve auditing of the core QEMU code, it would be ideal to be
able to separate the core QEMU functionality from utility
functionality by moving the utility functionality into its own
process. This process will be referred to as the QEMU client below.
Separating as in moving code outside of qemu.git, making code optionally
built in, making code optionally built in or loadable as a separate
executable that is automatically launched, or making code always built
outside the main executable?
I'm very nervous about having a large number of daemons necessary to run
QEMU. I think a reasonable approach would be a single front-end daemond.
Once QAPI is merged, there is a very incremental approach we can take for
this sort of work. Take your favorite subsystem (like gdbstub or SDL) and
make it only use QMP apis. Once we're only using QMP internally in a
subsystem, then building it out of the main QEMU and using libqmp should be
Back from a day off playing with power drills and concrete walls :)
Sorry I should have made it a little more clear, it was obvious to me,
but not written down:
The idea is to keep everything as part of the QEMU package, ie. part of
qemu.git. My idea is really to have one QEMU host daemon and one QEMU
client, which provides the various services. You type make and you get
two binaries instead of one. We could allow other daemons to connect to
the host daemon, but that wouldn't be a primary target for this in my
book, and I am not sure we really want to do this.
It is absolutely vital for me that we do not make things much more
complicated for users with this move. I don't want to get into a
situation where we start forcing external packages or daemons in order
to run basic QEMU. If we start requiring such, we have failed! However,
I think it is a reasonable compromise to have one daemon you launch, and
then a simple client you launch straight after which will then provide
the same/similar views and interfaces that users are used to when they
launch current QEMU (monitor, vnc server etc).
I think the challenge with this approach is defining an IPC mechanism
that is robust enough to support it. For instance, on one end of the
spectrum we have Spice, where shared memory paired with some mechanism
for IO notification between the client/server might make sense. But then
we have things like the human monitor where a socket interface or pipe
is clearly more the more straight-forward route.
We may find that it more desirable to have multiple classes of client
components, each contain within a client process with it's own IPC
mechanism. Although, multiple IPC mechanisms doesn't sound particularly
enticing either...but 2 might not be so unreasonable.
I hope this clarifies things.