Kconfig: ARCH=x86

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

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.

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

Hi Andreas.

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

Absolutely. This would be userspace-visible ABI breakage.

-hpa

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

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

-hpa

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

-hpa

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

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.

---
 arch/x86/Makefile |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

index 116b03a..7aa1dc6 100644
@@ -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