[PATCH] x86/asm/msr: Retract msr-index.h

[PATCH] x86/asm/msr: Retract msr-index.h

[Borislav Petkov]

From: Borislav Petkov <bp@suse.de>

This header containing all MSRs and respective bit definitions got
exported to userspace in conjunction with the big uapi shuffle.

But, it doesn't have anything to do in the uapi headers because
userspace can do its own MSR defines and exporting them from the
kernel blocks us from doing cleanups/renames in that header. Which is
ridiculous - it is not kernel's job to export such a header and keep
MSRs list and their names stable.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
---
 arch/x86/include/{uapi => }/asm/msr-index.h | 0
 tools/power/x86/turbostat/Makefile          | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename arch/x86/include/{uapi => }/asm/msr-index.h (100%)

diff --git a/arch/x86/include/uapi/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
similarity index 100%
rename from arch/x86/include/uapi/asm/msr-index.h
rename to arch/x86/include/asm/msr-index.h
diff --git a/tools/power/x86/turbostat/Makefile b/tools/power/x86/turbostat/Makefile
index 4039854560d0..e367b1a85d70 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -9,7 +9,7 @@ endif
 
 turbostat : turbostat.c
 CFLAGS +=	-Wall
-CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"'
+CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"'
 
 %: %.c
 	@mkdir -p $(BUILD_OUTPUT)
-- 
2.3.5

Re: [PATCH] x86/asm/msr: Retract msr-index.h

[Borislav Petkov]

On Wed, Jun 03, 2015 at 02:41:48PM +0200, Borislav Petkov wrote:
> This header containing all MSRs and respective bit definitions got
> exported to userspace in conjunction with the big uapi shuffle.
> 
> But, it doesn't have anything to do in the uapi headers because
> userspace can do its own MSR defines and exporting them from the
> kernel blocks us from doing cleanups/renames in that header. Which is
> ridiculous - it is not kernel's job to export such a header and keep
> MSRs list and their names stable.

Here's v2. Needed to *not* include it into uapi/asm/msr.h either.

---
From: Borislav Petkov <bp@suse.de>
Date: Wed, 3 Jun 2015 14:37:05 +0200
Subject: [PATCH] x86/asm/msr: Retract msr-index.h

This header containing all MSRs and respective bit definitions got
exported to userspace in conjunction with the big uapi shuffle.

But, it doesn't have anything to do in the uapi headers because
userspace can do its own MSR defines and exporting them from the
kernel blocks us from doing cleanups/renames in that header. Which is
ridiculous - it is not kernel's job to export such a header and keep
MSRs list and their names stable.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: David Howells <dhowells@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
---
 arch/x86/include/{uapi => }/asm/msr-index.h | 0
 arch/x86/include/asm/msr.h                  | 3 ++-
 arch/x86/include/uapi/asm/msr.h             | 2 --
 tools/power/x86/turbostat/Makefile          | 2 +-
 4 files changed, 3 insertions(+), 4 deletions(-)
 rename arch/x86/include/{uapi => }/asm/msr-index.h (100%)

diff --git a/arch/x86/include/uapi/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
similarity index 100%
rename from arch/x86/include/uapi/asm/msr-index.h
rename to arch/x86/include/asm/msr-index.h
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index de36f22eb0b9..441ecf83d81a 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -1,13 +1,14 @@
 #ifndef _ASM_X86_MSR_H
 #define _ASM_X86_MSR_H
 
-#include <uapi/asm/msr.h>
+#include "msr-index.h"
 
 #ifndef __ASSEMBLY__
 
 #include <asm/asm.h>
 #include <asm/errno.h>
 #include <asm/cpumask.h>
+#include <uapi/asm/msr.h>
 
 struct msr {
 	union {
diff --git a/arch/x86/include/uapi/asm/msr.h b/arch/x86/include/uapi/asm/msr.h
index 155e51048fa4..c41f4fe25483 100644
--- a/arch/x86/include/uapi/asm/msr.h
+++ b/arch/x86/include/uapi/asm/msr.h
@@ -1,8 +1,6 @@
 #ifndef _UAPI_ASM_X86_MSR_H
 #define _UAPI_ASM_X86_MSR_H
 
-#include <asm/msr-index.h>
-
 #ifndef __ASSEMBLY__
 
 #include <linux/types.h>
diff --git a/tools/power/x86/turbostat/Makefile b/tools/power/x86/turbostat/Makefile
index 4039854560d0..e367b1a85d70 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -9,7 +9,7 @@ endif
 
 turbostat : turbostat.c
 CFLAGS +=	-Wall
-CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"'
+CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"'
 
 %: %.c
 	@mkdir -p $(BUILD_OUTPUT)
-- 
2.3.5

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] x86/asm/msr: Retract msr-index.h

[H. Peter Anvin]

On 06/03/2015 11:21 AM, Borislav Petkov wrote:
> On Wed, Jun 03, 2015 at 02:41:48PM +0200, Borislav Petkov wrote:
>> This header containing all MSRs and respective bit definitions got
>> exported to userspace in conjunction with the big uapi shuffle.
>>
>> But, it doesn't have anything to do in the uapi headers because
>> userspace can do its own MSR defines and exporting them from the
>> kernel blocks us from doing cleanups/renames in that header. Which is
>> ridiculous - it is not kernel's job to export such a header and keep
>> MSRs list and their names stable.
> 
> Here's v2. Needed to *not* include it into uapi/asm/msr.h either.

I really like the patch, but the description is awful.

How about: "x86/uapi: <asm/msr.h> is not a UAPI"

	-hpa

Re: [PATCH] x86/asm/msr: Retract msr-index.h

[Borislav Petkov]

On Wed, Jun 03, 2015 at 11:56:33AM -0700, H. Peter Anvin wrote:
> I really like the patch, but the description is awful.
> 
> How about: "x86/uapi: <asm/msr.h> is not a UAPI"

Sure. Commit text needs improvement too?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] x86/asm/msr: Retract msr-index.h

[H. Peter Anvin]

On 06/03/2015 01:06 PM, Borislav Petkov wrote:
> On Wed, Jun 03, 2015 at 11:56:33AM -0700, H. Peter Anvin wrote:
>> I really like the patch, but the description is awful.
>>
>> How about: "x86/uapi: <asm/msr.h> is not a UAPI"
> 
> Sure. Commit text needs improvement too?
> 

The commit text is fine, IMO.

	-hpa

Re: [PATCH] x86/asm/msr: Retract msr-index.h

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> On 06/03/2015 11:21 AM, Borislav Petkov wrote:
> > On Wed, Jun 03, 2015 at 02:41:48PM +0200, Borislav Petkov wrote:
> >> This header containing all MSRs and respective bit definitions got
> >> exported to userspace in conjunction with the big uapi shuffle.
> >>
> >> But, it doesn't have anything to do in the uapi headers because
> >> userspace can do its own MSR defines and exporting them from the
> >> kernel blocks us from doing cleanups/renames in that header. Which is
> >> ridiculous - it is not kernel's job to export such a header and keep
> >> MSRs list and their names stable.
> > 
> > Here's v2. Needed to *not* include it into uapi/asm/msr.h either.
> 
> I really like the patch, but the description is awful.
> 
> How about: "x86/uapi: <asm/msr.h> is not a UAPI"

So a small nit: a simple statement of fact is not really a proper commit title.
A commit title should express what the patch _does_.

Missing leading verbs are really passive-aggressive on the reader of a flow of 
commit titles - such as when reading a short log or a one-line git log.

Something like:

	x86/uapi: Remove <asm/msr.h> from the list of exported UAPI headers

or so would work fine with me.

Thanks!

	Ingo

Re: [PATCH] x86/asm/msr: Retract msr-index.h

[Borislav Petkov]

On Thu, Jun 04, 2015 at 08:09:12AM +0200, Ingo Molnar wrote:
> Something like:
> 
> 	x86/uapi: Remove <asm/msr.h> from the list of exported UAPI headers
> 
> or so would work fine with me.

I did this - this is maximally descriptive IMO. :-)

---
From: Borislav Petkov <bp@suse.de>
Date: Wed, 3 Jun 2015 14:37:05 +0200
Subject: [PATCH] x86/uapi: Do not export <asm/msr-index.h> as part of the user API headers

This header containing all MSRs and respective bit definitions got
exported to userspace in conjunction with the big UAPI shuffle.

But, it doesn't belong in the UAPI headers because userspace can do
its own MSR defines and exporting them from the kernel blocks us from
doing cleanups/renames in that header. Which is ridiculous - it is not
kernel's job to export such a header and keep MSRs list and their names
stable.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: David Howells <dhowells@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
---
 arch/x86/include/{uapi => }/asm/msr-index.h | 0
 arch/x86/include/asm/msr.h                  | 3 ++-
 arch/x86/include/uapi/asm/msr.h             | 2 --
 tools/power/x86/turbostat/Makefile          | 2 +-
 4 files changed, 3 insertions(+), 4 deletions(-)
 rename arch/x86/include/{uapi => }/asm/msr-index.h (100%)

diff --git a/arch/x86/include/uapi/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
similarity index 100%
rename from arch/x86/include/uapi/asm/msr-index.h
rename to arch/x86/include/asm/msr-index.h
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index de36f22eb0b9..441ecf83d81a 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -1,13 +1,14 @@
 #ifndef _ASM_X86_MSR_H
 #define _ASM_X86_MSR_H
 
-#include <uapi/asm/msr.h>
+#include "msr-index.h"
 
 #ifndef __ASSEMBLY__
 
 #include <asm/asm.h>
 #include <asm/errno.h>
 #include <asm/cpumask.h>
+#include <uapi/asm/msr.h>
 
 struct msr {
 	union {
diff --git a/arch/x86/include/uapi/asm/msr.h b/arch/x86/include/uapi/asm/msr.h
index 155e51048fa4..c41f4fe25483 100644
--- a/arch/x86/include/uapi/asm/msr.h
+++ b/arch/x86/include/uapi/asm/msr.h
@@ -1,8 +1,6 @@
 #ifndef _UAPI_ASM_X86_MSR_H
 #define _UAPI_ASM_X86_MSR_H
 
-#include <asm/msr-index.h>
-
 #ifndef __ASSEMBLY__
 
 #include <linux/types.h>
diff --git a/tools/power/x86/turbostat/Makefile b/tools/power/x86/turbostat/Makefile
index 4039854560d0..e367b1a85d70 100644
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -9,7 +9,7 @@ endif
 
 turbostat : turbostat.c
 CFLAGS +=	-Wall
-CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"'
+CFLAGS +=	-DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"'
 
 %: %.c
 	@mkdir -p $(BUILD_OUTPUT)
-- 
2.3.5

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] x86/asm/msr: Retract msr-index.h

[Ingo Molnar]

* Borislav Petkov <bp@alien8.de> wrote:

> On Thu, Jun 04, 2015 at 08:09:12AM +0200, Ingo Molnar wrote:
> > Something like:
> > 
> > 	x86/uapi: Remove <asm/msr.h> from the list of exported UAPI headers
> > 
> > or so would work fine with me.
> 
> I did this - this is maximally descriptive IMO. :-)
> 
> ---
> From: Borislav Petkov <bp@suse.de>
> Date: Wed, 3 Jun 2015 14:37:05 +0200
> Subject: [PATCH] x86/uapi: Do not export <asm/msr-index.h> as part of the user API headers

This sounds good to me too.

Thanks,

	Ingo

Re: [PATCH] x86/asm/msr: Retract msr-index.h

[Len Brown]

>  tools/power/x86/turbostat/Makefile          | 2 +-

Acked-by: Len Brown <len.brown@intel.com>

One of the reasons I put turbostat in the kernel tree was so that it
would be easy
to have 1 copy of the truth for MSR definitions.  I'm okay with
treating it like a kernel file
and following any MSR name changes in the kernel.
That is much more attractive to me than managing a 2nd set of definitions
in user-space that would diverge.

thanks,
-Len Brown
Intel Open Source Technology Center