lkml.org 
[lkml]   [2013]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/8] um: Create defconfigs for i386 and x86_64
On 09/26/2013 12:35 PM, Richard Weinberger wrote:
> Am 26.09.2013 12:20, schrieb Ramkumar Ramachandra:
>> Richard Weinberger wrote:
>>> This patch is based on: https://lkml.org/lkml/2013/7/4/396
>>>
>>> Cc: Ramkumar Ramachandra <artagnon@gmail.com>
>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>> ---
>>> arch/um/configs/i386_defconfig | 954 +++++++++++++++++++++++++++++++++++++++
>>> arch/um/configs/x86_64_defconfig | 943 ++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 1897 insertions(+)
>>> create mode 100644 arch/um/configs/i386_defconfig
>>> create mode 100644 arch/um/configs/x86_64_defconfig
>>
>> First, I'm pissed that the upstream tree doesn't build and run out of
>> the box months after I submitted a fix in July (and it's September
>> now). Fact that you dropped my sane patches aside and decided to write
>> a much larger series aside, user-mode Linux in upstream is broken.
>> This means that any user who does:
>>
>> $ ARCH=um make defconfig
>> $ ARCH=um make
>>
>> will end up with a *broken* Linux _today_. Unless the user is living
>> in the Stone Age with a 32-bit computer, this is what she will see
>> when she attempts to boot up Linux:

:-{

Grmpf

There are a lot of 32 bit user land linux installation (beside my own,
look at the x86 Gentoo world) in the wild - even running on modern 64bit
CPUs. The simple reason is that those installations run fine and the
performance "boost" of 64bit often isn't worth a new reinstallation.

--
the stone-age-Toralf

>
> Not here.
>
>> $ file linux
>> linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
>> dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not
>> stripped
>> $ ./linux ubd0=busybox-rootfs
>> [...]
>> Kernel panic - not syncing: No init found. Try passing init= option
>> to kernel. See Linux Documentation/init.txt for guidance.
>
> I don't know that rootfs but it looks like there is no init.
>
>> CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc2-00083-g4b97280 #1
>> 0b869fbc 08272f87 0b869fdc 0820c5cd 00000001 00000000 00000000 00000000
>> 0b869fe8 0820c126 08252593 0b869ff8 08059317 00000000 00000001 00000000
>> 00000000 0b869f94: [<0805a11c>] show_stack+0x54/0x8c
>> 0b869fb4: [<0820e3c8>] dump_stack+0x16/0x1b
>> 0b869fc8: [<0820c5cd>] panic+0x67/0x149
>> 0b869fe0: [<0820c126>] kernel_init+0xab/0xaf
>> 0b869fec: [<08059317>] new_thread_handler+0x63/0x7c
>> 0b869ffc: [<00000000>] 0x0
>>
>>
>> EIP: 0023:[<f7717430>] CPU: 0 Not tainted ESP: 002b:ffc386dc EFLAGS: 00000296
>> Not tainted
>> EAX: 00000000 EBX: 000063ba ECX: 00000013 EDX: 000063ba
>> ESI: 000063b6 EDI: 00000002 EBP: ffc38708 DS: 002b ES: 002b
>> 0b869f44: [<0806aff4>] show_regs+0xb4/0xbc
>> 0b869f70: [<0805b23b>] panic_exit+0x20/0x36
>> 0b869f84: [<0808521b>] notifier_call_chain+0x28/0x4b
>> 0b869fac: [<0808526c>] atomic_notifier_call_chain+0x15/0x17
>> 0b869fbc: [<0820c5de>] panic+0x78/0x149
>> 0b869fe0: [<0820c126>] kernel_init+0xab/0xaf
>> 0b869fec: [<08059317>] new_thread_handler+0x63/0x7c
>> 0b869ffc: [<00000000>] 0x0
>>
>> [1] 25526 abort (core dumped) linux ubd0=busybox-rootfs
>> %
>>
>> Rubbish.
>
> UML core dumps at panic() by design.
>
>> When I rebase my original patches (exactly 2 small independent
>> patches) onto the new upstream, stuff works as usual. If you're not
>> convinced, try the um-build branch from
>> https://github.com/artagnon/linux for yourself.
>
>> Are you against accepting good patches and stalling work? What is your
>> plan exactly?
>
> Sure, my great plan is to destroy Linux. I work for Microsoft. ;-)
>
> Seriously, my plan is to get rid of SUBARCH, that's why I did not push your patches
> upstream and I've send the rid of SUBARCH patch series.
> It turned out that other archs depend on SUBARCH too therefore some more thinking is needed.
> Time passed, merge window closed, $dayjob needed some attention...
>
> That said, your "arch/um: make it work with defconfig and x86_64" patch is also not perfect.
> "make defconfig ARCH=um SUBARCH=x86" will create x86_64 defconfig, which is wrong and breaks existing
> setups.
> Secondly, what stops you from running "make defconfig ARCH=um SUBARCH=x86_64" to run your x86_64 bit
> userspace?
>
> Thanks,
> //richard
>


--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
--
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/

\
 
 \ /
  Last update: 2013-09-27 12:01    [W:1.992 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site