Re: [PATCH 02/11] x86, fpu: rename xfeature_bit

[Dave Hansen]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/