From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757124AbbHZQKO (ORCPT <rfc822;w@1wt.eu>);
	Wed, 26 Aug 2015 12:10:14 -0400
Received: from www.sr71.net ([198.145.64.142]:58220 "EHLO blackbird.sr71.net"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1757107AbbHZQKL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 26 Aug 2015 12:10:11 -0400
Message-ID: <55DDE4E1.3090203@sr71.net>
Date: Wed, 26 Aug 2015 09:10:09 -0700
From: Dave Hansen <dave@sr71.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Borislav Petkov <bp@alien8.de>
CC: dave.hansen@linux.intel.com, mingo@redhat.com, x86@kernel.org,
        fenghua.yu@intel.com, tim.c.chen@linux.intel.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/11] x86, fpu: rename xfeature_bit
References: <20150825201201.CF766C1B@viggo.jf.intel.com> <20150825201202.61B614D6@viggo.jf.intel.com> <20150826160627.GB7508@nazgul.tnic>
In-Reply-To: <20150826160627.GB7508@nazgul.tnic>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.