On Tue, Jul 8, 2014 at 12:20 PM, Richard Weinberger <richard@xxxxxx> wrote: > Am 08.07.2014 10:16, schrieb Konstantin Khlebnikov: >> On Tue, Jul 8, 2014 at 12:01 PM, Richard Weinberger >> <richard.weinberger@xxxxxxxxx> wrote: >>> On Tue, Jul 8, 2014 at 7:48 AM, Konstantin Khlebnikov <koct9i@xxxxxxxxx> wrote: >>>> On Tue, Jul 8, 2014 at 2:05 AM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >>>>> On Sat, 05 Jul 2014 15:22:38 +0400 Konstantin Khlebnikov <koct9i@xxxxxxxxx> wrote: >>>>> >>>>>> This fixes command # make checkstack for i386/x86_64. >>>>>> Looks like $UTS_MACHINE is exactly what scripts/checkstack.pl needs. >>>>>> >>>>>> By default $UTS_MACHINE is equal to $ARCH, but some arch/${ARCH}/Makefile >>>>>> overrides it. This patch updates it also in arch/x86/Makefile.um >>>>>> >>>>>> broken in ffee0de ("x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT") >>>>> >>>>> The changelog doesn't describe the bug which is being fixed. It should >>>>> do so please. If there are any compiler/make error messages then those >>>>> should be included. >>>>> >>>> >>>> Oh, ok. checkstalk.pl needs either i386 or x86_64, x86 isn't enough. >>>> >>>> $ make checkstack >>>> objdump -d vmlinux $(find . -name '*.ko') | \ >>>> perl /home/blind/src/linux-stable/scripts/checkstack.pl x86 >>>> wrong or unknown architecture "x86" >>> >>> And now we need ARCH, SUBARCH and UTS_MACHINE on UML? :-( >> >> Nope UTS_MACHINE is autodetected, see hunk Makefile.x86 in my patch. >> >> I thought about cleaning this part of UML. >> For example we could move arch/x86/um into arch/um/x86 and use # make >> ARCH=um/x86 > > No way. We moved the x86 stuff to arch/x86/ a few Years ago by design. Ok, fine. We could leave it in arch/x86/um and use make ARCH=x86/um > >> after collecting this stuff together it woud be easier to get rid of >> forever-broken parts. >> As I see UML has been designed to work everywhere but SMP seem never worked >> as well as any host os except of linux or other arch except x86. > > Currently UML runs only on x86_32/64. > Adding/fixing SMP support should be doable. This might be quite difficult on top of current ptrace-based design. I thought about running userspace in kvm context, this might be much faster than ptrace but requires indirect uaccess like for 4gb-split. But it's very unlikely that I'll find time for that. > > Thanks, > //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html