Hi, Eric
On Thu, 20 Jan 2011 08:20:20 -0700
Eric Blake <eblake(a)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(a)mxm.nes.nec.co.jp>