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/
Home Products Support Community News


Re: [Xen-devel] [PATCH][RFC] FPU LWP 1/5: clean up the FPU code

To: Wei Huang <wei.huang2@xxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][RFC] FPU LWP 1/5: clean up the FPU code
From: Keir Fraser <keir@xxxxxxx>
Date: Fri, 15 Apr 2011 10:20:13 +0100
Delivery-date: Fri, 15 Apr 2011 02:21:30 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:user-agent:date:subject:from:to :message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=OjhpVRa0+yKQkTQ1YNjnqB3+fZikjBSnaSb9O3oL63w=; b=Cg3eiDU6yiL39Z/lg6PBFXWV1j0DBrNYdbG+R2K+6J3yAmigNVvGixyzJC4de+1EV0 P4pnkfXCn8SyJ0l7A6gBt1uSMuFBwEqTG+SwNJeelNrdOkzuSf91FGtM6OL7NnW6YLt+ JeGR42HRAhsHbbmsWOgM/P4fNfyvG6RuscdAk=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=CBKYUotGUkBi//+gD5fvScdhcNG1xDTD4HOCHTdNT4IRyj+Nh5WSQnEKmvq8oBkPgS uHOoCz1ApRmHkZJZhlK8c8Yqw5C4cbzYNf/nfmbGx8sGSUos0sPxI7Tdn/BIN7jSrBgn Ag3ozXq70GXHj2wRZox0rptL8/sB5c6mBWHI8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DA75B22.1010702@xxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acv7TlMT8R7R1vb5gEuLbgGsms8OnQ==
Thread-topic: [Xen-devel] [PATCH][RFC] FPU LWP 1/5: clean up the FPU code
User-agent: Microsoft-Entourage/
On 14/04/2011 21:37, "Wei Huang" <wei.huang2@xxxxxxx> wrote:

> This patch reorganizes and cleans up the FPU code. Main changes include:
> 1. Related functions are re-arranged together.
> 2. FPU save/restore code are extracted out as independent functions
> (fsave/frstor, fxsave/fxrstor, xsave/xrstor).
> 3. Two FPU entry functions, fpu_save() and fpu_restore(), are defined.
> They utilize xsave/xrstor to save/restore FPU state if CPU supports
> extended state. Otherwise they fall back to fxsave/fxrstor or fsave/frstor.


If you're going to clean this up, please don't politely skirt around the
existing file- and function-name conventions. The fact is that i387/fpu is
but one item of state handled by XSAVE/XRSTOR and friends. Thus it is the
tail wagging the dog to keep all the new mechanism in files and functions
called {i387,fpu}*. I'd prefer you to move some or all functionality into
newly-named files and functions -- perhaps using a prefix like xstate_ on
functions and sticking it all in files xstate.[ch]. Perhaps the old i387
files would disappear completely, or perhaps you'll find a few bits and
pieces logically remain in them, I don't mind either way as long as
everything is in a logical place with a logical name.

The naming in your 3rd patch is also unnecessarily confusing: is it really
clear the difference between *_reload and *_restore, for example, that one
is done on context switch and the other on #NM? We need better names; for
 xstate_save: Straightforward I guess as we always unlazily save everything
that's dirty straight away during context switch.
 xstate_restore_lazy: Handle stuff we restore lazily on #NM.
 xstate_restore_eager: Handle stuff we restore unconditionally (if in use by
the guest) on ctxt switch.

These names would mean a lot more to me than what you chose. However, feel
free to work out a comprehensive naming scheme that you think works best.
All I'm saying is that our current naming scheme is already pretty crappy,
and you make it quite a bit worse by following the existing direction way
too much!

 -- Keir

> Signed-off-by: Wei Huang <wei.huang2@xxxxxxx>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list

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