On Wed, 2006-09-06 at 10:17 +0100, Steven Smith wrote:
> > On Mon, 2006-09-04 at 10:02 +0100, Steven Smith wrote:
> > > > diff -r a2a8f1ed16ea -r 2b360c6b44fa tools/python/xen/xend/image.py
> > > > --- a/tools/python/xen/xend/image.py Sat Sep 02 15:22:19 2006 -0400
> > > > +++ b/tools/python/xen/xend/image.py Sat Sep 02 15:23:32 2006 -0400
> > > > @@ -20,8 +20,10 @@ import os, string
> > > > import os, string
> > > > import re
> > > > import math
> > > > +import signal
> > > Why?
> > Because it's used to kill a process and doing a lazy import of things
> > like this is a good way to drive a man crazy ;-)
> I'd drop this from this patch, since it's not really required or
> particularly useful.
>
> Don't let that stop you from doing a separate cleanup patch,
> though. :)
Hint taken and sent ;-)
> > > > import xen.lowlevel.xc
> > > > +import xen.util.auxbin
> > > > from xen.xend import sxp
> > > > from xen.xend.XendError import VmError
> > > > from xen.xend.XendLogging import log
> > > > @@ -189,6 +191,68 @@ class LinuxImageHandler(ImageHandler):
> > > > cmdline = self.cmdline,
> > > > ramdisk = self.ramdisk,
> > > > features = self.vm.getFeatures())
> > > > +
> > > > + def configure(self, imageConfig, deviceConfig):
> > > Does this really belong in class LinuxImageHandler?
> > Right now, it's only implemented for Linux -- with a proof of concept
> > for elsewhere, I could see move it to being generic instead. But right
> > now, it's Linux specific
> The other PV devices have their own Controller classes
> (BlkifController, NetifController, etc.). Why is the framebuffer
> special?
Because I was able to "liberally use" a lot of the hvm code. Also, for
consistency with the hvm code, the framebuffer bits show up as part of
the image section of the sexpr rather than device. Since one of the big
goals here (at least, from my point of view) is making full and para
virt domains more consistent, I'd like to keep to that.
If you feel strongly, I can look at reworking it
> > > > + def createDeviceModel(self):
> > > Maybe call ImageHandler.createDeviceModel?
> > The HVM one doesn't -- perhaps both should although currently the
> > comment in the superclass is such that it's not going to define anything
> I think that's a bug in the HVM version, personally. I'll have a look
> at it later.
There are whole diatribes written on when and whether you should call
superclass methods -- if the hvm one changes, I'll change for PV ;-)
Jeremy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home