δΊ 2012-11-14 18:32, Paolo Bonzini ει:
Il 14/11/2012 10:55, Wenchao Xia ha scritto:
In order to resolve OOM issue, I am trying wrap all APIs using
sunrpc, need some suggestion before coding.
Is the client/server approach really necessary or can you write a
library that invokes qemu-nbd/qemu-img?
If there is a startup cost problem with qemu-img it may be possible to
add an interactive mode (like qemu-io) where qemu-img stays open and
responds to commands (maybe in JSON encoding).
The difference between this and the RPC approach is that you can write a
relatively thin NBD and qemu-img library with the tools that already
exist today.
In fact, I think this is not our issue. If libvirt wants to use
libqblock but have a problem with OOM exit, they can write their own
wrappers to do the simple tasks they need, or just keep on using
qemu-img with JSON output (possibly extending it and keeping the
functionality upstream). For many of those tasks, it may turn out that
qemu-img extensions would be useful anyway.
Paolo
Personally agree, but I want to add a simple wrapper to let libqblock
get user faster. In this way I guess best choice now is making rpc
client and server not mirrored in implemention, server provides
r/w/info retrieving capabilities via XDR protocol, client keeps
the API unchanged but implement a bit different than server, which
may archieve the same effect as invoking qemu-img inside without string
parsing.
Not sure if libqblock now is blocked by OOM issue as 1st version to
be reviewed. If you think it must be resolved first, I would add this
wrapper quickly.
--
Best Regards
Wenchao Xia
