public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Dave Jones <davej@redhat.com>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: Fix MTRR strings definition.
Date: Tue, 24 Aug 2004 13:17:35 +0200	[thread overview]
Message-ID: <20040824131735.3980c21a.ak@suse.de> (raw)
In-Reply-To: <20040824110001.GD28237@redhat.com>

On Tue, 24 Aug 2004 12:00:01 +0100
Dave Jones <davej@redhat.com> wrote:

> On Tue, Aug 24, 2004 at 08:17:29AM +0200, Andi Kleen wrote:
>  > On Tue, 24 Aug 2004 00:23:20 +0100
>  > Dave Jones <davej@redhat.com> wrote:
>  > 
>  > > Instead of deleting the extern from include/asm/mtrr.h, I believe
>  > > the correct fix would be to move the strings back to the include file
>  > > where they belong.
>  > > The reason behind this, is that there are userspace apps (admittedly
>  > > few, but we even ship two in Documentation/mtrr.txt) that rely upon
>  > > these definitions being in that header.  This has been broken for
>  > > all 2.6 releases so far. Patch below fixes things back the way it
>  > > was in 2.4
>  > 
>  > That's rather ugly. It would be cleaner to just have a 
>  > macro that expands to the strings, and everybody who wants to use
>  > it declares an own array using that macro.
> 
> feel free to go rewrite the userspace that uses this.

Umm - since when do we care about user space gratuously including kernel 
headers?  I normally avoid breaking user space by this without need, but depending
on a static variable declaration in a header is really far too ugly
to be kept alive.


>  > > Andi, I don't have gcc 3.5 to hand, I trust this fixes whatever
>  > > problem you saw there too ?
>  > 
>  > 3.5 doesn't like it when something is declared both extern and static.
>  > Your new patch has this problem again.
> 
> The extern definitions no longer exist.

Your patch was: 

--- latest-FC2/include/asm-x86_64/mtrr.h~	2004-08-24 00:20:17.377436336 +0100
+++ latest-FC2/include/asm-x86_64/mtrr.h	2004-08-24 00:21:04.137327752 +0100
@@ -69,6 +69,19 @@
 #define MTRR_TYPE_WRBACK     6
 #define MTRR_NUM_TYPES       7
 
+#ifdef MTRR_NEED_STRINGS
+static char *mtrr_strings[MTRR_NUM_TYPES] =
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+{
+	"uncachable",		/* 0 */
+	"write-combining",	/* 1 */
+	"?",			/* 2 */
+	"?",			/* 3 */
+	"write-through",	/* 4 */
+	"write-protect",	/* 5 */
+	"write-back",		/* 6 */
+};
+#endif
+
 #ifdef __KERNEL__
 
 extern char *mtrr_strings[MTRR_NUM_TYPES];
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-Andi

  reply	other threads:[~2004-08-24 11:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-23 23:23 Fix MTRR strings definition Dave Jones
2004-08-24  6:17 ` Andi Kleen
2004-08-24 11:00   ` Dave Jones
2004-08-24 11:17     ` Andi Kleen [this message]
2004-08-24 11:22       ` Dave Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040824131735.3980c21a.ak@suse.de \
    --to=ak@suse.de \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox