[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xenfb: make restartable
Markus Armbruster, le Fri 15 Aug 2008 08:39:06 -0400, a écrit : > > + if (!strcmp(dev->devicetype, "vfb")) { > > + if (dev->xenfb->pixels) { > > + munmap(dev->xenfb->pixels, dev->xenfb->fb_len); > > + dev->xenfb->pixels = NULL; > > + } > > + } > > } > > > > > > The check for vfb is ugly. The only alternative I can see is fb == > dev->xenfb->fb. Matter of taste. Hum, that was what I had written previously actually. I don't see why it is "ugly", in that pixels is a device resource. It should probably be in xenfb->fb actually. > > @@ -653,6 +656,16 @@ static int xenfb_on_state_change(struct > > not much point in us continuing. */ > > return -1; > > case XenbusStateInitialising: > > + if (dev->state != XenbusStateClosed) > > + /* Do not let a domain make us skip the closing state */ > > + return 0; > > Why does this work? It's meant to not work. If the frontend is not playing well (going through the closing state), then ignore what it's doing until it plays well. An alternative could be to just shut down. In any case, we don't want to let it drive us to remapping something else without unmapping the previous fb. > > + xenfb_switch_state(dev, XenbusStateInitWait); > > + xs_unwatch(dev->xenfb->xsh, dev->otherend, ""); > > + if (!strcmp(dev->devicetype, "vkbd")) { > > + fprintf(stderr, "FB: Waiting for KBD backend creation\n"); > > + xenfb_wait_for_frontend(&dev->xenfb->kbd, > > xenfb_frontend_initialized_kbd); > > + } > > + break; > > Man, I hate this state machine... I agree :) > Gerd's new one is much clearer (I asked for that). Then since 3.3 is about to be released, we'd probably have this change with it. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |