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@xxxxxxxxx>
Signed-off-by: Richard Weinberger <richard@xxxxxx>
---
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-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
