Hi, Eric On Thu, 20 Jan 2011 08:20:20 -0700 Eric Blake <eblake@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list