[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.