Re: [PATCH] Paravirt framebuffer support in xend [3/5]

[Steven Smith <sos22-xen@srcf.ucam.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2339 bytes --]

> > > > 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 ;-)
Thanks.

> > > > >  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.
I'd be happier if the framebuffer stuff was in the device section of
the sexp, because it is a device, and there's no reason in principle
why a domain couldn't have more than one of them.

> 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.
This is a good reason, but I think that the display configuration was
put in image in the HVM sexp for reasons of expediency rather than
correctness.  It'd be good not to copy that if we don't have to.

Even better would be to move the HVM configuration information to the
right place, but that's probably a job for another time.

> If you feel strongly, I can look at reworking it
How much of a pain is this going to be?

Steven.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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