Kconfig: ARCH=x86

Kconfig: ARCH=x86

[Andreas Herrmann]

Hi,

I have just some minor remarks wrt the commit message for
daa93fab824f2b8c35bd11670c7fab2f32b2de5f - 'x86: enable "make
ARCH=x86"'. (Based on my observations when testing the stuff on 64bit
and 32bit hosts with Linus' tree v2.6.24-rc2-640-g8c08634.)

For randconfig we have now the following behaviour.  (The table shows
whether the resulting configuration is for 32 or 64-bit.)

# make randconfig [ARCH=...] [K64BIT=]

option \ host arch      | 32bit         | 64bit
=====================================================
./.                     | 32bit         | 64bit
ARCH=x86                | 32bit/64bit   | 32bit/64bit
ARCH=x86 K64BIT=n       | 32bit         | 32bit
ARCH=x86 K64BIT=y       | 64bit         | 64bit
ARCH=x86_64             | 64bit         | 64bit
ARCH=x86_64 K64BIT=n    | 32bit         | 32bit
ARCH=x86_64 K64BIT=y    | 64bit         | 64bit

Basically this means if you are addicted to randconfig (like I am) and
want to compile-test the entire range of possible 32-bit _and_ 64-bit
configurations you have to use "ARCH=x86" on te commmand line.

For menuconfig (config, oldconfig, silentoldconfig) we have the
following default selections, depending on whether there exists an old
.config file or not.  Especially this means that the default for
CONFIG_64BIT does not depend on any command line option like "ARCH=x86
K64BIT=y".

option \ host arch      | 32bit         | 64bit
=================================================
                        | (w/o any .config file)
all relevant options    | 32bit         | 64bit
-------------------------------------------------
                        | (with old 32-bit .config)
all relevant options    | 32bit         | 32bit
------------------------+---------------+--------
                        | (with old 64-bit .config)
all relevant options    | 64bit         | 64bit

I don't know whether the above is the desired behaviour. But that's
what I have observed on my machines. And now that I know how it works
I can live with it ;-)

BTW, is the x86 kernel build documented somewhere?
At a first glance I didn't find anything suitable under Documentation/.
Maybe some explanation (like the above) should be added there.


Regards,

Andreas

Kconfig: ARCH=x86 causes wrong utsname.machine

[Andreas Herrmann]

The new ARCH=x86 kernel build causes weired machine strings on 32-bit.
For a cross-compiled kernel I have

	 $ uname -m
	 x66_64

For a kernel natively built on a 32 bit machine I have

	$ uname -m  
	x66

Looking at the sources, I think that utsname->machine was initially
set as "x86_64" and "x86", respectively.
But in arch/x86/kernel/cpu/bugs.c in check_bugs() the second character
is set to '6' on my K7.

I think the right solution for that problem is to use "x86_64" as the
machine name for 64-bit and to keep the old "i[3456]86" strings for
32-bit kernels.

Several tools (e.g. the kernel build itself) will be confused
otherwise (*).


Regards,

Andreas


(*) Example:
$ uname -m
x66_64
$ make menuconfig
Makefile:425: /projects/linux-2.6-x86/arch/x66_64/Makefile: No such file or directory
make: *** No rule to make target `/projects/linux-2.6-x86/arch/x66_64/Makefile'.  Stop.

Re: Kconfig: ARCH=x86 causes wrong utsname.machine

[H. Peter Anvin]

Andreas Herrmann wrote:
> The new ARCH=x86 kernel build causes weired machine strings on 32-bit.
> For a cross-compiled kernel I have
> 
> 	 $ uname -m
> 	 x66_64
> 
> For a kernel natively built on a 32 bit machine I have
> 
> 	$ uname -m  
> 	x66
> 
> Looking at the sources, I think that utsname->machine was initially
> set as "x86_64" and "x86", respectively.
> But in arch/x86/kernel/cpu/bugs.c in check_bugs() the second character
> is set to '6' on my K7.
> 
> I think the right solution for that problem is to use "x86_64" as the
> machine name for 64-bit and to keep the old "i[3456]86" strings for
> 32-bit kernels.

Absolutely.  This would be userspace-visible ABI breakage.

	-hpa

Re: Kconfig: ARCH=x86 causes wrong utsname.machine

[Sam Ravnborg]

On Fri, Nov 16, 2007 at 07:20:15AM -0800, H. Peter Anvin wrote:
> Andreas Herrmann wrote:
> >The new ARCH=x86 kernel build causes weired machine strings on 32-bit.
> >For a cross-compiled kernel I have
> >
> >	 $ uname -m
> >	 x66_64
> >
> >For a kernel natively built on a 32 bit machine I have
> >
> >	$ uname -m  
> >	x66
> >
> >Looking at the sources, I think that utsname->machine was initially
> >set as "x86_64" and "x86", respectively.
> >But in arch/x86/kernel/cpu/bugs.c in check_bugs() the second character
> >is set to '6' on my K7.
> >
> >I think the right solution for that problem is to use "x86_64" as the
> >machine name for 64-bit and to keep the old "i[3456]86" strings for
> >32-bit kernels.
> 
> Absolutely.  This would be userspace-visible ABI breakage.

Any good suggestions here???
UTS_MACHINE is set in top-level Makefile and if we specify
make ARCH=x86
we do not know if i386 or x86_&4 is correct until the configuration
has been read.

Should we report a "make ARCH=x86" as uname -m == x86??

	Sam

Re: Kconfig: ARCH=x86 causes wrong utsname.machine

[H. Peter Anvin]

Sam Ravnborg wrote:
> On Fri, Nov 16, 2007 at 07:20:15AM -0800, H. Peter Anvin wrote:
>> Andreas Herrmann wrote:
>>> The new ARCH=x86 kernel build causes weired machine strings on 32-bit.
>>> For a cross-compiled kernel I have
>>>
>>> 	 $ uname -m
>>> 	 x66_64
>>>
>>> For a kernel natively built on a 32 bit machine I have
>>>
>>> 	$ uname -m  
>>> 	x66
>>>
>>> Looking at the sources, I think that utsname->machine was initially
>>> set as "x86_64" and "x86", respectively.
>>> But in arch/x86/kernel/cpu/bugs.c in check_bugs() the second character
>>> is set to '6' on my K7.
>>>
>>> I think the right solution for that problem is to use "x86_64" as the
>>> machine name for 64-bit and to keep the old "i[3456]86" strings for
>>> 32-bit kernels.
>> Absolutely.  This would be userspace-visible ABI breakage.
> 
> Any good suggestions here???
> UTS_MACHINE is set in top-level Makefile and if we specify
> make ARCH=x86
> we do not know if i386 or x86_&4 is correct until the configuration
> has been read.
> 
> Should we report a "make ARCH=x86" as uname -m == x86??
> 

That would break 5 years of a stable ABI.  I don't think that is even 
remotely feasible.

	-hpa

Re: Kconfig: ARCH=x86 causes wrong utsname.machine

[H. Peter Anvin]

H. Peter Anvin wrote:
>>
>> Should we report a "make ARCH=x86" as uname -m == x86??
>>
> 
> That would break 5 years of a stable ABI.  I don't think that is even 
> remotely feasible.
> 

Make that 5 years for x86-64, 16 years for i386...

	-hpa

Re: Kconfig: ARCH=x86 causes wrong utsname.machine

[Sam Ravnborg]

> >
> >Any good suggestions here???
> >UTS_MACHINE is set in top-level Makefile and if we specify
> >make ARCH=x86
> >we do not know if i386 or x86_&4 is correct until the configuration
> >has been read.
> >
> >Should we report a "make ARCH=x86" as uname -m == x86??
> >
> 
> That would break 5 years of a stable ABI.  I don't think that is even 
> remotely feasible.

I will try to cook up a patch that sets CONFIG_UTS_MACHINE
and then we will use that value unless it is undefined in which
case we fall back to UTS_MACHINE (as today).

	Sam

[PATCH] x86: fix UTS_MACHINE to be "i386" for 32-bit build and "x86_64" for 64-bit build

[Andreas Herrmann]

On Sat, Nov 17, 2007 at 08:57:15AM +0100, Sam Ravnborg wrote:
> > >
> > >Any good suggestions here???
> > >UTS_MACHINE is set in top-level Makefile and if we specify
> > >make ARCH=x86
> > >we do not know if i386 or x86_&4 is correct until the configuration
> > >has been read.
> > >
> > >Should we report a "make ARCH=x86" as uname -m == x86??
> > >
> > 
> > That would break 5 years of a stable ABI.  I don't think that is even 
> > remotely feasible.
> 
> I will try to cook up a patch that sets CONFIG_UTS_MACHINE
> and then we will use that value unless it is undefined in which
> case we fall back to UTS_MACHINE (as today).


IMHO we shouldn't add another config option.
Just correctly set UTS_MACHINE in arch/x86/Makefile will do it.

I wasn't aware where the machine name came from.
Now that I know that (and shamelessly copying ideas from s390;-)
it is easy to fix. See attached patch.

Testing a crosscompiled 32-bit-kernel I now get
    # uname -m
    i686
on my K7.

Other tests will follow. But patch looks sane and should go mainline asap, I think.


Regards,

Andreas

--
x86: fix UTS_MACHINE to be "i386" for 32-bit build and "x86_64" for 64-bit build.

Signed-off-by: Andreas Herrmann <aherrman@arcor.de>
---
 arch/x86/Makefile |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 116b03a..7aa1dc6 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -11,10 +11,9 @@ endif
 $(srctree)/arch/x86/Makefile%: ;
 
 ifeq ($(CONFIG_X86_32),y)
+        UTS_MACHINE := i386
         include $(srctree)/arch/x86/Makefile_32
 else
+        UTS_MACHINE := x86_64
         include $(srctree)/arch/x86/Makefile_64
 endif
-
-
-
-- 
1.5.3.4

Re: Kconfig: ARCH=x86

[Andreas Herrmann]

On Fri, Nov 16, 2007 at 12:14:46PM +0100, Andreas Herrmann wrote:
> BTW, is the x86 kernel build documented somewhere?
> At a first glance I didn't find anything suitable under Documentation/.
> Maybe some explanation (like the above) should be added there.

When the ARCH=x86 build is documented, some words about
cross-compilation should be added:

  (1) To compile a 32-bit kernel on a 64-bit system you have to
  Disable 64bit support in menuconfig (config, oldconfig etc.).  A
  subsequent kernel compile will build a 32-bit kernel.  No cross
  compiler is needed.

  (2) To compile a 64-bit kernel on a 32-bit system you have to switch
  on 64-bit support in menuconfig (or config, oldconfig, etc.).  For
  the subsequent kernel compile a cross compiler (supporting 64-bit)
  is needed. You have to use a command line like

        # make CROSS_COMPILE=x86_64-pc-linux-gnu-

  to cross compile your kernel.


Regards,

Andreas

Re: Kconfig: ARCH=x86

[Sam Ravnborg]

Hi Andreas.

On Fri, Nov 16, 2007 at 12:14:46PM +0100, Andreas Herrmann wrote:
> Hi,
> 
> I have just some minor remarks wrt the commit message for
> daa93fab824f2b8c35bd11670c7fab2f32b2de5f - 'x86: enable "make
> ARCH=x86"'. (Based on my observations when testing the stuff on 64bit
> and 32bit hosts with Linus' tree v2.6.24-rc2-640-g8c08634.)
> 
> For randconfig we have now the following behaviour.  (The table shows
> whether the resulting configuration is for 32 or 64-bit.)
> 
> # make randconfig [ARCH=...] [K64BIT=]
> 
> option \ host arch      | 32bit         | 64bit
> =====================================================
> ./.                     | 32bit         | 64bit
> ARCH=x86                | 32bit/64bit   | 32bit/64bit
> ARCH=x86 K64BIT=n       | 32bit         | 32bit
> ARCH=x86 K64BIT=y       | 64bit         | 64bit
> ARCH=x86_64             | 64bit         | 64bit
> ARCH=x86_64 K64BIT=n    | 32bit         | 32bit
> ARCH=x86_64 K64BIT=y    | 64bit         | 64bit

To make the table complete you need to consider
make ARCH=i386

Basically is goes like this:
With x86 the default is 32 bit but can be set to 64-bit with K64BIT=y
With x86_64 the default is 64-bit but K64BIT take precedence
With i386 the default is 32 bit but K64BIT takes precedence


All that said I am going to revert the K64BIT possibility.
Roman posted a patch earlier that allows us to based on ARCH setting
select between 32-bit or 64-bit based on ARCH= alone.

	Sam

[PATCH] x86: simplify "make ARCH=x86" and fix kconfig all.config

[Sam Ravnborg]

Simplify "make ARCH=x86" and fix kconfig so we again
can set 64BIT in all.config.

For a fix the diffstat is nice:
 6 files changed, 3 insertions(+), 36 deletions(-)

The patch reverts these commits:
0f855aa64b3f63d35a891510cf7db932a435c116
-> kconfig: add helper to set config symbol from environment variable

2a113281f5cd2febbab21a93c8943f8d3eece4d3
-> kconfig: use $K64BIT to set 64BIT with all*config targets

Roman Zippel pointed out that kconfig supported string
compares so the additional complexity introduced by the
above two patches were not needed.

With this patch we have following behaviour:

# make {allno,allyes,allmod,rand}config [ARCH=...]
option \ host arch      | 32bit         | 64bit
=====================================================
./.                     | 32bit         | 64bit
ARCH=x86                | 32bit         | 32bit
ARCH=i386               | 32bit         | 32bit
ARCH=x86_64             | 64bit         | 64bit

The general rule are that ARCH= and native architecture
takes precedence over the configuration.
So make ARCH=i386 [whatever] will always build a 32-bit
kernel no matter what the configuration says.
The configuration will be updated to 32-bit if it was
configured to 64-bit and the other way around.

This behaviour is consistent with previous behaviour so
no suprises here.

make ARCH=x86 will per default result in a 32-bit kernel
but as the only ARCH= value x86 allow the user to select
between 32-bit and 64-bit using menuconfig. 

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Herrmann <aherrman@arcor.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
---

Linus - please apply to -rc3.

Note: This patch does not fix the uname -m issue - to do so
Andreas' patch is needed.

	Sam

 Makefile                    |    4 +---
 README                      |    2 --
 arch/x86/Kconfig            |    4 ++--
 scripts/kconfig/conf.c      |    1 -
 scripts/kconfig/confdata.c  |   27 ---------------------------
 scripts/kconfig/lkc_proto.h |    1 -
 6 files changed, 3 insertions(+), 36 deletions(-)

diff --git a/Makefile b/Makefile
index 9c9c4bf..b32963a 100644
--- a/Makefile
+++ b/Makefile
@@ -200,11 +200,9 @@ SRCARCH 	:= $(ARCH)
 # Additional ARCH settings for x86
 ifeq ($(ARCH),i386)
         SRCARCH := x86
-        K64BIT  := n
 endif
 ifeq ($(ARCH),x86_64)
         SRCARCH := x86
-        K64BIT  := y
 endif
 
 KCONFIG_CONFIG	?= .config
@@ -341,7 +339,7 @@ KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
 KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 
 export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
-export ARCH SRCARCH K64BIT CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
+export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
 export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
 export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 
diff --git a/README b/README
index 592f8a2..159912c 100644
--- a/README
+++ b/README
@@ -194,8 +194,6 @@ CONFIGURING the kernel:
    "make *config" checks for a file named "all{yes/mod/no/random}.config"
    for symbol values that are to be forced.  If this file is not found,
    it checks for a file named "all.config" to contain forced values.
-   Finally it checks the environment variable K64BIT and if found, sets
-   the config symbol "64BIT" to the value of the K64BIT variable.
    
 	NOTES on "make config":
 	- having unnecessary drivers will make the kernel bigger, and can
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1eb5997..368864d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -3,8 +3,8 @@ mainmenu "Linux Kernel Configuration for x86"
 
 # Select 32 or 64 bit
 config 64BIT
-	bool "64-bit kernel"
-	default n
+	bool "64-bit kernel" if ARCH = "x86"
+	default ARCH = "x86_64"
 	help
 	  Say yes to build a 64-bit kernel - formerly known as x86_64
 	  Say no to build a 32-bit kernel - formerly known as i386
diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index c6bee85..a38787a 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -591,7 +591,6 @@ int main(int ac, char **av)
 			conf_read_simple(name, S_DEF_USER);
 		else if (!stat("all.config", &tmpstat))
 			conf_read_simple("all.config", S_DEF_USER);
-		conf_set_env_sym("K64BIT", "64BIT", S_DEF_USER);
 		break;
 	default:
 		break;
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index e4fa3f3..e0f402f 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -145,33 +145,6 @@ static int conf_set_sym_val(struct symbol *sym, int def, int def_flags, char *p)
 	return 0;
 }
 
-/* Read an environment variable and assign the value to the symbol */
-int conf_set_env_sym(const char *env, const char *symname, int def)
-{
-	struct symbol *sym;
-	char *p;
-	int def_flags;
-
-	p = getenv(env);
-	if (p) {
-		char warning[200];
-		sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
-		conf_filename = warning;
-		def_flags = SYMBOL_DEF << def;
-		if (def == S_DEF_USER) {
-			sym = sym_find(symname);
-			if (!sym)
-				return 1;
-		} else {
-			sym = sym_lookup(symname, 0);
-			if (sym->type == S_UNKNOWN)
-				sym->type = S_OTHER;
-		}
-		conf_set_sym_val(sym, def, def_flags, p);
-	}
-	return 0;
-}
-
 int conf_read_simple(const char *name, int def)
 {
 	FILE *in = NULL;
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index dca294e..4d09f6d 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -1,7 +1,6 @@
 
 /* confdata.c */
 P(conf_parse,void,(const char *name));
-P(conf_set_env_sym,int,(const char *envname, const char *symname, int def));
 P(conf_read,int,(const char *name));
 P(conf_read_simple,int,(const char *name, int));
 P(conf_write,int,(const char *name));

[PATCH] x86: fix UTS_MACHINE to be i386 for 32-bit build and x86_64 for 64-bit build

[Andreas Herrmann]

On Sat, Nov 17, 2007 at 03:37:31PM +0100, Sam Ravnborg wrote:
> 
> Note: This patch does not fix the uname -m issue - to do so
> Andreas' patch is needed.
> 
> 	Sam

Linus,

The issue Sam refers to is that UTS_MACHINE is set to "x86" instead of
"i386" or "x86_64" when building with ARCH=x86. Thus the new kernel
when booted will give either "x86" on x86_64 and many i386 systems or
even "x66" on other i386 systems for 'uname -m'.

Many tools rely on the usual values of "x86_64", "i366" and "i686"
here. So we shouldn't change this.

Attached patch fixes that issue. Please apply.


Regards,

Andreas

--
x86: fix UTS_MACHINE to be i386 for 32-bit build and x86_64 for 64-bit build

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andreas Herrmann <aherrman@arcor.de>
---
 arch/x86/Makefile |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 116b03a..7aa1dc6 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -11,10 +11,9 @@ endif
 $(srctree)/arch/x86/Makefile%: ;
 
 ifeq ($(CONFIG_X86_32),y)
+        UTS_MACHINE := i386
         include $(srctree)/arch/x86/Makefile_32
 else
+        UTS_MACHINE := x86_64
         include $(srctree)/arch/x86/Makefile_64
 endif
-
-
-
-- 
1.5.3.4

Re: [PATCH] x86: fix UTS_MACHINE to be i386 for 32-bit build and x86_64 for 64-bit build

[Sam Ravnborg]

On Mon, Nov 19, 2007 at 10:34:37AM +0100, Andreas Herrmann wrote:
> On Sat, Nov 17, 2007 at 03:37:31PM +0100, Sam Ravnborg wrote:
> > 
> > Note: This patch does not fix the uname -m issue - to do so
> > Andreas' patch is needed.
> > 
> > 	Sam
> 
> Linus,
> 
> The issue Sam refers to is that UTS_MACHINE is set to "x86" instead of
> "i386" or "x86_64" when building with ARCH=x86. Thus the new kernel
> when booted will give either "x86" on x86_64 and many i386 systems or
> even "x66" on other i386 systems for 'uname -m'.
> 
> Many tools rely on the usual values of "x86_64", "i366" and "i686"
> here. So we shouldn't change this.

Andreas - I will suggest you to submit a new patch with
a better changelog where you jsut describe what you fix.
The above explanations looks a bit weird if read stand alone.

You can always add additional comments after the line containing:
---

In this way it is not included in the changelog but Linus can read it.

Anyway - your patch has my ack.

	Sam

> 
> Attached patch fixes that issue. Please apply.
> 
> 
> Regards,
> 
> Andreas
> 
> --
> x86: fix UTS_MACHINE to be i386 for 32-bit build and x86_64 for 64-bit build
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Roman Zippel <zippel@linux-m68k.org>
> Signed-off-by: Andreas Herrmann <aherrman@arcor.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

> ---
>  arch/x86/Makefile |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 116b03a..7aa1dc6 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -11,10 +11,9 @@ endif
>  $(srctree)/arch/x86/Makefile%: ;
>  
>  ifeq ($(CONFIG_X86_32),y)
> +        UTS_MACHINE := i386
>          include $(srctree)/arch/x86/Makefile_32
>  else
> +        UTS_MACHINE := x86_64
>          include $(srctree)/arch/x86/Makefile_64
>  endif
> -
> -
> -
> -- 
> 1.5.3.4
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: fix UTS_MACHINE to be i386 for 32-bit build and x86_64 for 64-bit build

[Andreas Herrmann]

On Mon, Nov 19, 2007 at 11:41:29AM +0100, Sam Ravnborg wrote:
> On Mon, Nov 19, 2007 at 10:34:37AM +0100, Andreas Herrmann wrote:
> > On Sat, Nov 17, 2007 at 03:37:31PM +0100, Sam Ravnborg wrote:
> > > 
> > > Note: This patch does not fix the uname -m issue - to do so
> > > Andreas' patch is needed.
> > > 
> > > 	Sam
> > 
> > Linus,
> > 
> > The issue Sam refers to is that UTS_MACHINE is set to "x86" instead of
> > "i386" or "x86_64" when building with ARCH=x86. Thus the new kernel
> > when booted will give either "x86" on x86_64 and many i386 systems or
> > even "x66" on other i386 systems for 'uname -m'.
> > 
> > Many tools rely on the usual values of "x86_64", "i366" and "i686"
> > here. So we shouldn't change this.
> 
> Andreas - I will suggest you to submit a new patch with
> a better changelog where you jsut describe what you fix.
> The above explanations looks a bit weird if read stand alone.

Ok, I'll resend the patch with an updated changelog asap.

> You can always add additional comments after the line containing:
> ---
> 
> In this way it is not included in the changelog but Linus can read it.
> 
> Anyway - your patch has my ack.

Thanks,


Andreas