Re: [RFC] PVFB: Add refresh period to XenStore parameters?

[Samuel Thibault <samuel.thibault@eu.citrix.com>]

Markus Armbruster, le Tue 06 May 2008 15:50:08 +0200, a écrit :
> > +    for (i = 0, cons = page->in_cons; cons != prod; i++, cons++) {
> 
> Purpose of i ?

It was needed in the case of kbd, but not here indeed.

> > +        int notified_active;   /* Did we request update */
> 
> Tab, please, if it's not too much trouble.  Mixing tabs and spaces for
> indentation makes diffs unnecessarily hard to read.

I agree and fixed it, the problem is just that xen has various
indentation/tab practices, so no default configuration can work :)

> > +/*
> > + * Backend idleness report
> > + * Backend sends it when the output window is somehow non visible
> > + * (minimized, no client, etc.)
> > + */
> > +#define XENFB_TYPE_BACKEND_STATUS 1
> > +
> > +#define XENFB_BACKEND_STATUS_IDLE 0
> > +#define XENFB_BACKEND_STATUS_ACTIVE 1
> > +
> > +struct xenfb_backend_status
> > +{
> > +    uint8_t type;    /* XENFB_TYPE_BACKEND_STATUS */
> > +    uint8_t status;  /* XENFB_BACKEND_STATUS_* */
> > +};
> 
> I'm not entirely happy with the protocol defined here.

Right, I'm not sure of what we would ideally want to express. I can see
three use cases:

- The output is fully active, we want frequent update notification
  (that is the assumed permanent state up to now)
- The output is not visible, update notification is useless.
- The output is visible in reduced conditions, for instance a thumbnail
  in a VMs management tool, update notification don't really need to be
  sent often.  We could have the backend explicitely request updates
  from the frontend when it wants a new thumbnail (this is needed e.g.
  in HVM text mode, in which the guest output is not directly mapped
  through PVFB, so an explicit refresh is needed).

Instead of expressing idleness or "status", maybe we could rather
express whether periodic update notifications are wanted or not, and let
the backend request an explicit update notification when it feels the
need for one (low-frequency thumbnail update). It has the advantage of
only talking about the PVFB protocol itself and not something around it
(idleness of the actual output).  That is also backward compatible in
that a frontend which doesn't know these two events will just continue
sending periodic update notifications, which is fine for the backend.

Samuel