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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox