3:53 a.m.
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
4:11 a.m.
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
4:15 a.m.
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
5:09 a.m.
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 :|
5:15 a.m.
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
5:17 a.m.
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 :|
5:21 a.m.
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
5:34 a.m.
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 :|
10:13 a.m.
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
10:21 a.m.
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 :|
5768
days inactive
5768
days old
9 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Gihan Munasinghe -
John Levon -
Stefan de Konink