From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: In-Reply-To: References: <1377073172-3662-1-git-send-email-richard@nod.at> <1377073172-3662-3-git-send-email-richard@nod.at> <52441025.9030308@nod.at> <52441407.9010603@nod.at> <52442108.1020304@nod.at>

MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----5QY7030VZWCJNE5X8N17B2HC1XHSHG" From: Richard Weinberger Date: Thu, 26 Sep 2013 15:56:07 +0200 Message-ID: <6ca106c1-3ba4-4d49-97ad-9f400045dd2c@email.android.com> Subject: Re: [PATCH 2/8] um: Do not use SUBARCH To: Geert Uytterhoeven , Ramkumar Ramachandra Cc: Linux-Arch , Michal Marek , Ralf Baechle , Paul Mundt , Jeff Dike , Guan Xuetao , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , linux-kbuild , LKML , linux-m68k , Linux MIPS Mailing List , Linux-sh list , uml-devel List-ID: ------5QY7030VZWCJNE5X8N17B2HC1XHSHG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Correct. Users expect Form SUBARCH=x86 a 32bit kernel. Geert Uytterhoeven schrieb: >On Thu, Sep 26, 2013 at 3:13 PM, Ramkumar Ramachandra > wrote: >> Ramkumar Ramachandra wrote: >>> Richard Weinberger wrote: >>>> I told you already that "make defconfig ARCH=um SUBARCH=x86" will >spuriously >>>> create a x86_64 config on x86_64. >>>> This breaks existing setups. >>> >>> I'll fix this and resubmit soon. >> >> Wait a minute. You're now arguing about whether the generic "x86" >> means i386 or x86_64. Its meaning is already defined in >> arch/x86/Kconfig and arch/x86/um/Kconfig: see the config 64BIT. >Unless >> i386 is explicitly specified, the default is to build a 64-bit >kernel. >> That is already defined for a normal Linux kernel, and user-mode >Linux >> should not break that convention. So, in the example you pulled out >of >> your hat: >> >> $ make defconfig ARCH=um SUBARCH=x86 >> >> the user should expect a 64-bit build, and not an i386 build as you >> say. Both my patches are correct, and the "regression" that you >> pointed out is a red herring. > >Sorry for chiming in, but... what about cross compiling? >SUBARCH=x86 should give you a 32-bit ia32 kernel, right? > >Gr{oetje,eeting}s, > > Geert > >-- >Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- >geert@linux-m68k.org > >In personal conversations with technical people, I call myself a >hacker. But >when I'm talking to journalists I just say "programmer" or something >like that. > -- Linus Torvalds -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------5QY7030VZWCJNE5X8N17B2HC1XHSHG Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Correct. Users expect Form SUBARCH=x86 a 32bit kernel.

Geert Uytterhoeven <geert@linux-m68k.org> schrieb:

On Thu, Sep 26, 2013 at 3:13 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
Ramkumar Ramachandra wrote:
Richard Weinberger wrote:
I told you already that "make defconfig ARCH=um SUBARCH=x86" will spuriously
create a x86_64 config on x86_64.
This breaks existing setups.

I'll fix this and resubmit soon.

Wait a minute. You're now arguing about whether the generic "x86"
means i386 or x86_64. Its meaning is already defined in
arch/x86/Kconfig and
arch/x86/um/Kconfig: see the config 64BIT. Unless
i386 is explicitly specified, the default is to build a 64-bit kernel.
That is already defined for a normal Linux kernel, and user-mode Linux
should not break that convention. So, in the example you pulled out of
your hat:

$ make defconfig ARCH=um SUBARCH=x86

the user should expect a 64-bit build, and not an i386 build as you
say. Both my patches are correct, and the "regression" that you
pointed out is a red herring.

Sorry for chiming in, but... what about cross compiling?
SUBARCH=x86 should give you a 32-bit ia32 kernel, right?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus
Torvalds

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ------5QY7030VZWCJNE5X8N17B2HC1XHSHG--