On Tue, Jul 8, 2014 at 12:50 PM, Richard Weinberger <[email protected]> wrote: > Am 08.07.2014 10:47, schrieb Konstantin Khlebnikov: >> On Tue, Jul 8, 2014 at 12:33 PM, Richard Weinberger <[email protected]> wrote: >>> Am 08.07.2014 10:30, schrieb Konstantin Khlebnikov: >>>> On Tue, Jul 8, 2014 at 12:20 PM, Richard Weinberger <[email protected]> wrote: >>>>> Am 08.07.2014 10:16, schrieb Konstantin Khlebnikov: >>>>>> On Tue, Jul 8, 2014 at 12:01 PM, Richard Weinberger >>>>>> <[email protected]> wrote: >>>>>>> On Tue, Jul 8, 2014 at 7:48 AM, Konstantin Khlebnikov >>>>>>> <[email protected]> wrote: >>>>>>>> On Tue, Jul 8, 2014 at 2:05 AM, Andrew Morton >>>>>>>> <[email protected]> wrote: >>>>>>>>> On Sat, 05 Jul 2014 15:22:38 +0400 Konstantin Khlebnikov >>>>>>>>> <[email protected]> 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 >>> >>> I don't like this. Please keep ARCH=um as is. >>> >>>>> >>>>>> 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. >>> >>> Erm, UML is a systemcall emulator based on ptrace(). >>> If you make it use any KVM backend there is 0 usecase for UML because we >>> can just use qemu/kvmtool. >> >> But kernel stays in userspace, so it could be easily debugged. >> It's like merge kvmtool+linux into one application. > > You can already do this with qemu. It has a -gdb switch.
I know. But debugging/profiling of kernel code is much easier when it runs in userspace. I think this is the last use case where uml might beat normal hardware accelerated qemu/kvm. But without SMP and with that high overhead on each syscall and context/mm switch it's mostly useless. > > Thanks, > //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
