Hi, Eric On Thu, 20 Jan 2011 08:20:20 -0700 Eric Blake <eblake@redhat.com> wrote:
On 01/20/2011 05:13 AM, Daniel P. Berrange wrote:
* virSysinfoRead() This API is completely internal. But DMI type1 information(dmidecode -t1) is useful for above purpose, because it's one of the information which suppose to processing capacity about host machine.
I want to export virSysinfoRead() to user.
I wouldn't want to export the API, because that would require us to expose some complex structures in the public ABI. I think we'd just want to expose the data in the host capabilities XML, or have an API to query the XML of just the sysinfo on its own.
You are not the first person to request some way of getting at the host's sysinfo from a libvirt API, so the idea of exporting something makes sense (just not virSysinfoRead in its current form). Personally, I like the idea of:
char *virConnectGetSysinfo(virConnectPtr)
which returns just the XML <sysinfo> block for a given host. Also, including <sysinfo> in the larger XML of virCopnnectGetCapabilities() makes sense.
I think it's better than exporting virSysinfoRead(). I'll try to implement virConnectGetSysinfo(). But I have one question. Why do you think <sysinfo> block should include XML of virConnectGetCapabilities()? I think, virConnectGetSysinfo() returns just a hardware information about host machine. On the other hand, virConnectGetCapabilities() returns what support the host machine. These are little bit different, so I don't think virConnectGetSysinfo() needs virConnectGetCapabilities()'s information. Do I misunderstand? -- Minoru Usui <usui@mxm.nes.nec.co.jp>