lkml.org 
[lkml]   [2015]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 084/208] x86/fpu: Rename xsave.header::xstate_bv to 'xfeatures'

* Dave Hansen <dave.hansen@linux.intel.com> wrote:

> On 05/05/2015 10:49 AM, Ingo Molnar wrote:
> > 'xsave.header::xstate_bv' is a misnomer - what does 'bv' stand for?
>
> xstate_bv is what it is called in the SDM. [...]

So I'm not attached to the ::xfeatures name (we could name it
xstate_mask, etc.) - but xstate_bv? It's really nonsensical IMHO - and
I wanted it to be more obvious.

We could put the SDM name into a comment, next to the field
definition? Something like, if 'xfeatures' is too long:

struct xstate_header {
u64 xfeat; /* xstate components, SDM: XSTATE_BV */
u64 xfeat_comp; /* compacted xstate components, SDM: XCOMP_BV */
u64 reserved[6];
} __attribute__((packed));

or so? Then if you grep for 'XSTATE_BV', you'll immediately see that
it's called xfeat_comp.

> [...] I'd really like to see the nomenclature match the SDM where
> it's sensible because it says lots of things like:
>
> XSAVES does not write to any parts of the XSAVE header other
> than the XSTATE_BV and XCOMP_BV fields.
>
> It's nice to have code that does:
>
> ...->xstate_bv
>
> to match up with that documentation IMNHO.

Where the SDM uses sensible names I'm all for that - but IMHO this is
not such a case.

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-05-05 20:41    [W:0.431 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site