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
fairly easy.
Hi Anthony,
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).