On Tue, Jul 8, 2014 at 12:50 PM, Richard Weinberger <richard@xxxxxx> wrote:
> Am 08.07.2014 10:47, schrieb Konstantin Khlebnikov:
>> On Tue, Jul 8, 2014 at 12:33 PM, Richard Weinberger <richard@xxxxxx> wrote:
>>> Am 08.07.2014 10:30, schrieb Konstantin Khlebnikov:
>>>> 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
>>>
>>> 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-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
