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
|
Home