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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.