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: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] PVFB: Add refresh period to XenStore parameters?
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Tue, 06 May 2008 18:50:04 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 06 May 2008 09:50:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080506163255.GP4430@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (Samuel Thibault's message of "Tue\, 6 May 2008 17\:32\:55 +0100")
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>
References: <20080304144952.GA9230@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <873ar67anv.fsf@xxxxxxxxxxxxxxxxx> <20080304161220.GA9852@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080501175536.GV4797@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080502160638.GG4819@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <877ie917ix.fsf@xxxxxxxxxxxxxxxxx> <20080505091808.GC4497@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87ej8hysv6.fsf@xxxxxxxxxxxxxxxxx> <20080505165008.GP4497@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <87ve1rv8xb.fsf@xxxxxxxxxxxxxxxxx> <20080506163255.GP4430@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:

> 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 :)

I know...

>> > +/*
>> > + * 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

I think that's a better way to define this feature.

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

<Prev in Thread] Current Thread [Next in Thread>