[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55DDE4E1.3090203@sr71.net>
Date: Wed, 26 Aug 2015 09:10:09 -0700
From: Dave Hansen <dave@...1.net>
To: Borislav Petkov <bp@...en8.de>
CC: dave.hansen@...ux.intel.com, mingo@...hat.com, x86@...nel.org,
fenghua.yu@...el.com, tim.c.chen@...ux.intel.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/11] x86, fpu: rename xfeature_bit
On 08/26/2015 09:06 AM, Borislav Petkov wrote:
>> > -enum xfeature_bit {
>> > - XSTATE_BIT_FP,
>> > - XSTATE_BIT_SSE,
>> > - XSTATE_BIT_YMM,
>> > - XSTATE_BIT_BNDREGS,
>> > - XSTATE_BIT_BNDCSR,
>> > - XSTATE_BIT_OPMASK,
>> > - XSTATE_BIT_ZMM_Hi256,
>> > - XSTATE_BIT_Hi16_ZMM,
>> > +enum xfeature_nr {
>> > + XFEATURE_NR_FP,
>> > + XFEATURE_NR_SSE,
>> > + /*
>> > + * Values above here are "legacy states".
>> > + * Those below are "extended states".
>> > + */
>> > + XFEATURE_NR_YMM,
>> > + XFEATURE_NR_BNDREGS,
>> > + XFEATURE_NR_BNDCSR,
>> > + XFEATURE_NR_OPMASK,
>> > + XFEATURE_NR_ZMM_Hi256,
>> > + XFEATURE_NR_Hi16_ZMM,
> Why not simply
>
> s/NR_//
>
> ?
>
> I.e., XFEATURE_FP, XFEATURE_SSE and so on...
I wanted to differentiate them from the
#define XSTATE_FP (1 << XSTATE_BIT_FP)
#define XSTATE_SSE (1 << XSTATE_BIT_SSE)
defines below. Those are really XFEATURE_MASK_... I think this gets a
lots more clear if you have a pair of #defines like:
XFEATURE_NR_BNDREGS
XFEATURE_MASK_BNDREGS
It's pretty obvious what's going on there. What we have now is
XSTATE_BIT_BNDREGS
XSTATE_BNDREGS
which I find much less clear.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists