Re: [Qemu-devel] [RFC] libqblock OOM issue

[Wenchao Xia <xiawenc@linux.vnet.ibm.com>]

于 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