[XenPPC] Re: [Xen-devel] architecture-specific stuff in xend

2006-08-09 Thread Ewan Mellor
On Tue, Aug 08, 2006 at 04:59:53PM +0100, John Levon wrote:

 On Tue, Aug 08, 2006 at 10:34:25AM -0500, Hollis Blanchard wrote:
 
  Rather than having these inline tests everywhere (if os.uname()[4] in
  ('ia64', 'ppc64'):), would it make more sense to have some sort of
  architecture object, and do things like:
 
 It'd be good if it were slightly more general and covered other system
 stuff too (namely OS). On Solaris some of the Xen binaries/scripts live
 in different locations in order to meet our file system requirements.
 
  I'm not sure how/where to instantiate the arch object though.
 
 Presumably you could do the instance() singleton trick?

This being Python, you don't actually need singletons -- the containing module
is a singleton in its own right.  You can just write

Platform.py:

import os

if os.uname()[4] in ('ia64', 'ppc64'):
def init_reservation(mem_kb):
return something_else(mem_kb)

else:
def init_reservation(mem_kb):
return mem_kb

and then

import Platform
Platform.init_reservation(100)

will do the right thing.

Ewan.

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel


[XenPPC] Re: [Xen-devel] architecture-specific stuff in xend

2006-08-08 Thread Hollis Blanchard
On Tue, 2006-08-08 at 16:59 +0100, John Levon wrote:
 On Tue, Aug 08, 2006 at 10:34:25AM -0500, Hollis Blanchard wrote:
 
  Rather than having these inline tests everywhere (if os.uname()[4] in
  ('ia64', 'ppc64'):), would it make more sense to have some sort of
  architecture object, and do things like:
 
 It'd be good if it were slightly more general and covered other system
 stuff too (namely OS).

Sure, we could make it class Platform and have it represent an
architecture/OS pair.

 On Solaris some of the Xen binaries/scripts live
 in different locations in order to meet our file system requirements.

Does that impact code under tools/python/xen much?

  I'm not sure how/where to instantiate the arch object though.
 
 Presumably you could do the instance() singleton trick?

Not sure what you mean.

Actually, you bring up a good point: since we have no state (at least
not in the examples I'm thinking of), we really don't want/need a class;
a module would do just fine. So we could have separate files/modules
with just plain functions:

platform/ia64.py:
def init_reservation(mem_kb):
return something

platform/platform.py:
import xen.xend.platform.ia64 as platform

... or something. Like I said, I really don't know modules, but as long
as we don't have any arch-specific state we need to save, I'm pretty
sure modules are the right solution to this problem.

-- 
Hollis Blanchard
IBM Linux Technology Center


___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel


[XenPPC] Re: [Xen-devel] architecture-specific stuff in xend

2006-08-08 Thread John Levon
On Tue, Aug 08, 2006 at 11:15:18AM -0500, Hollis Blanchard wrote:

  On Solaris some of the Xen binaries/scripts live
  in different locations in order to meet our file system requirements.
 
 Does that impact code under tools/python/xen much?

Very little, but it does affect the location of the network scripts, for
example.

  Presumably you could do the instance() singleton trick?
 
 Not sure what you mean.

See XendRoot.py's instance().

 Actually, you bring up a good point: since we have no state (at least
 not in the examples I'm thinking of), we really don't want/need a class;
 a module would do just fine. So we could have separate files/modules
 with just plain functions:
 
 platform/ia64.py:
 def init_reservation(mem_kb):
   return something
 
 platform/platform.py:
 import xen.xend.platform.ia64 as platform

We'd still need something to import the right bits...

regards
john

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel