[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block

From: Wenchao Xia
Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API
Date: Mon, 16 Jul 2012 15:48:40 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

> On Fri, Jul 13, 2012 at 10:12:47AM +0100, Stefan Hajnoczi wrote:
On Tue, Jul 10, 2012 at 09:18:01AM +0200, Paolo Bonzini wrote:
Il 10/07/2012 07:37, Wenchao Xia ha scritto:

For getting the other metadata about the disk image you mention, another
possibility to is just make 'qemu-img info' return the data in a machine
parseable format, ie JSON&  make a client API for extracting data from
this JSON document.

   Thank u for the idea. The .so is introduced to let program access the
image more directly, parsing string is not so fast and it depends on
another program's stdout output, I hope to get a faster way.

I doubt you actually have profiled it.

I think speed is not the issue, instead it's just providing an API that
external programs can use.  Management tools, backup software, custom
administration tools, etc.  It's convenient to have an API.

Actually I think speed could well be quite relevant. In large deployments
it would not be surpising to see 1000's of images in a directory. If you
want to be able to query metadata about all of them at once, then being
able to open()+read(4k)+close() 1000 times is going to be dramatically
faster than doing fork()+execve(qemu-img) 1000 times.

  I tried to avoid fork() and execv() in the library as much as
possible. Dealing with another program's string output will cost quite
some codes about its timeout or exception error, more "native" code
seems better to me.

NB, I still think qemu-img info should be able to return a JSON parsable
data format, regardless of what any block library does.
  An option to qemu-img to specify output format may be a good way.


Best Regards

Wenchao Xia

reply via email to

[Prev in Thread] Current Thread [Next in Thread]