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.
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
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
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
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
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
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
> >
> >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
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 <[email protected]>
---
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