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. NB, I still think qemu-img info should be able to return a JSON parsable data format, regardless of what any block library does. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|