[libvirt] FreeNodeMemory
Hi Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure. I can see there is "virNodeGetFreeMemory(connection)" which currently not implemented for XEN.. I can add the patch to do this.. But I would like to clarify why we have not add "free_memory" in to the virNodeInfo structure.. Thanks -- Gihan Munasinghe R&D Team Leader XCalibre Communications Ltd. www.flexiscale.com
Gihan Munasinghe wrote:
Hi
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure.
I can see there is "virNodeGetFreeMemory(connection)" which currently not implemented for XEN.. I can add the patch to do this..
But I would like to clarify why we have not add "free_memory" in to the virNodeInfo structure..
Are you talking about free memory in dom 0 or the free memory on the system itself? Stefan
Stefan de Konink wrote:
Gihan Munasinghe wrote:
Hi
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure.
I can see there is "virNodeGetFreeMemory(connection)" which currently not implemented for XEN.. I can add the patch to do this..
But I would like to clarify why we have not add "free_memory" in to the virNodeInfo structure..
Are you talking about free memory in dom 0 or the free memory on the system itself?
Free memory available to create virtual machines on the system it self.. kind of like "xm info" gives out..
Stefan
-- Gihan Munasinghe R&D Team Leader XCalibre Communications Ltd. www.flexiscale.com
On Fri, Feb 06, 2009 at 09:53:04AM +0000, Gihan Munasinghe wrote:
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure.
All public structures are part of the public ABI and channot be changed once added. virNodeInfo existed long before the free memory API came about, hence its not present there.
I can see there is "virNodeGetFreeMemory(connection)" which currently not implemented for XEN..
Yes it is. In xen_unified.c the xenUnifiedNodeGetFreeMemory method provides the impl Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 09:53:04AM +0000, Gihan Munasinghe wrote:
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure.
All public structures are part of the public ABI and channot be changed once added.
In that case, when do you consider a .so bump an option? Stefan
On Fri, Feb 06, 2009 at 12:15:02PM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 09:53:04AM +0000, Gihan Munasinghe wrote:
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure.
All public structures are part of the public ABI and channot be changed once added.
In that case, when do you consider a .so bump an option?
Never. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 12:15:02PM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 09:53:04AM +0000, Gihan Munasinghe wrote:
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure. All public structures are part of the public ABI and channot be changed once added. In that case, when do you consider a .so bump an option?
Never.
So to put it bundly, then you have much confidence in your design skills if you never allow structures to be extended. What is wrong with releasing a new version of the API having these structures added, and deprecated logic/macro's for the functions that access them? Stefan
On Fri, Feb 06, 2009 at 12:21:30PM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 12:15:02PM +0100, Stefan de Konink wrote:
Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 09:53:04AM +0000, Gihan Munasinghe wrote:
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure. All public structures are part of the public ABI and channot be changed once added. In that case, when do you consider a .so bump an option?
Never.
So to put it bundly, then you have much confidence in your design skills if you never allow structures to be extended. What is wrong with releasing a new version of the API having these structures added, and deprecated logic/macro's for the functions that access them?
If a mistake / limitation is discovered in an API, then the solution is not to remove that API. The correct approach is to *add* a new API with the new desired signature / struct. This avoids breaking existing apps and preserves the ability to drop new releases into existing deployments without have to rebuild & change source all downstream apps. There is no compelling reason to bump the .so version when it is perfectly possible to add new APIs & structs without doing so. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Feb 06, 2009 at 11:09:31AM +0000, Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 09:53:04AM +0000, Gihan Munasinghe wrote:
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure.
All public structures are part of the public ABI and channot be changed once added. virNodeInfo existed long before the free memory API came about, hence its not present there.
Can I get a clarification about adding to the end of such structures? Often APIs do this with an explicit warning not to embed structures, take sizeof() etc. The other usual choice is to make the structure really opaque and provide accessors behind functions. If we don't do either, I'd be very worried by at least virDomainInterfaceStatsStruct, virDomainBlockStatsStruct, virNodeInfo, virVcpuInfo. We'll surely end up with a proliferation of virFoo2() calls for virFoo2Structs. regards, john
On Fri, Feb 06, 2009 at 11:13:37AM -0500, John Levon wrote:
On Fri, Feb 06, 2009 at 11:09:31AM +0000, Daniel P. Berrange wrote:
On Fri, Feb 06, 2009 at 09:53:04AM +0000, Gihan Munasinghe wrote:
Is there a specific reason for not having a "free_memory" with in the "virNodeInfo" structure.
All public structures are part of the public ABI and channot be changed once added. virNodeInfo existed long before the free memory API came about, hence its not present there.
Can I get a clarification about adding to the end of such structures? Often APIs do this with an explicit warning not to embed structures, take sizeof() etc. The other usual choice is to make the structure really opaque and provide accessors behind functions.
We've used a mix of techniques - the virDomain/Network/Storage structs are all opaque. The Interface/Block stats ones allow for sizeof(). The others are all fixed.
If we don't do either, I'd be very worried by at least virDomainInterfaceStatsStruct, virDomainBlockStatsStruct, virNodeInfo, virVcpuInfo. We'll surely end up with a proliferation of virFoo2() calls for virFoo2Structs.
The interface/block stats functions both take a sizeof() parameter to allow possible extension. NodeInfo/VcpuInfo do not. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
참여자 (4)
-
Daniel P. Berrange -
Gihan Munasinghe -
John Levon -
Stefan de Konink