|
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.
Daniel
-- Best Regards Wenchao Xia
[Prev in Thread] | Current Thread | [Next in Thread] |