WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Markus Armbruster <armbru@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] PVFB: Add refresh period to XenStore parameters?
From: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Date: Fri, 9 May 2008 11:31:50 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 09 May 2008 03:32:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <87hcd7c1gc.fsf@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>, Markus Armbruster <armbru@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
References: <20080505165008.GP4497@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87ve1rv8xb.fsf@xxxxxxxxxxxxxxxxx> <20080506163255.GP4430@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87lk2ntm0z.fsf@xxxxxxxxxxxxxxxxx> <20080506172959.GR4430@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <871w4emaxx.fsf@xxxxxxxxxxxxxxxxx> <20080507145426.GL4562@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <877ie5i4n7.fsf@xxxxxxxxxxxxxxxxx> <20080508150146.GO4365@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87hcd7c1gc.fsf@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.12-2006-07-14
Markus Armbruster, le Fri 09 May 2008 10:43:15 +0200, a écrit :
> > +    /* Will have to be disabled for frontends without feature-update */
> 
> I think I asked you to put this comment here, but is it still correct
> for current XENFB_TYPE_REFRESH_PERIOD semantics?

Considering the clarification of the semantic, it can be dropped indeed.

> > + *
> > + * If the frontend uses the advice, it should refresh and send an update 
> > event
> > + * in response to this event.
> >   */
> 
> You delete the bit about ignoring unknown events.  Oops.

Oops.

> What about this:

Ok.

> > +#define XENFB_TYPE_REFRESH_PERIOD 1
> > +
> > +struct xenfb_refresh_period
> > +{
> > +    uint8_t type;    /* XENFB_TYPE_UPDATE_PERIOD */
> > +    uint32_t period; /* period of refresh, in ms, 0 if no refresh is 
> > needed */
> > +};
> >  
> >  #define XENFB_IN_EVENT_SIZE 40
> >  
> >  union xenfb_in_event
> >  {
> >      uint8_t type;
> > +    struct xenfb_refresh_period refresh_period;
> 
> Time unit?

There is one in the structure above.

> I'd be tempted to use a frequency instead of a period, just because
> that doesn't require a special value for "no updates".  Strictly a
> matter of taste.

The "problem" of an integer frequency is that it does not permit a
period of more than one second, which may become a limit in some odd
situations (thousands of VMs waking every second?)

Samuel

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