Re: [RFC v2 03/37] lkl: architecture skeleton for Linux kernel library

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 26, 2019 at 12:00 AM Richard Weinberger
<richard.weinberger@xxxxxxxxx> wrote:
>
> On Fri, Nov 8, 2019 at 6:03 AM Hajime Tazaki <thehajime@xxxxxxxxx> wrote:
> >
> > From: Octavian Purdila <tavi.purdila@xxxxxxxxx>
> >
> > Adds the LKL Kconfig, vmlinux linker script, basic architecture
> > headers and miscellaneous basic functions or stubs such as
> > dump_stack(), show_regs() and cpuinfo proc ops.
> >
> > The headers we introduce in this patch are simple wrappers to the
> > asm-generic headers or stubs for things we don't support, such as
> > ptrace, DMA, signals, ELF handling and low level processor operations.
> >
> > The kernel configuration is automatically updated to reflect the
> > endianness of the host, 64bit support or the output format for
> > vmlinux's linker script. We do this by looking at the ld's default
> > output format.
> >
> > Signed-off-by: Andreas Abel <aabel@xxxxxxxxxx>
> > Signed-off-by: Conrad Meyer <cem@xxxxxxxxxxx>
> > Signed-off-by: Edison M. Castro <edisonmcastro@xxxxxxxxxxx>
> > Signed-off-by: H.K. Jerry Chu <hkchu@xxxxxxxxxx>
> > Signed-off-by: Hajime Tazaki <thehajime@xxxxxxxxx>
> > Signed-off-by: Jens Staal <staal1978@xxxxxxxxx>
> > Signed-off-by: Lai Jiangshan <jiangshanlai@xxxxxxxxx>
> > Signed-off-by: Levente Kurusa <levex@xxxxxxxxx>
> > Signed-off-by: Luca Dariz <luca.dariz@xxxxxxxxx>
> > Signed-off-by: Mark Stillwell <mark@xxxxxxxxxxxx>
> > Signed-off-by: Matthieu Coudron <mattator@xxxxxxxxx>
> > Signed-off-by: Michael Zimmermann <sigmaepsilon92@xxxxxxxxx>
> > Signed-off-by: Motomu Utsumi <motomuman@xxxxxxxxx>
> > Signed-off-by: Patrick Collins <pscollins@xxxxxxxxxx>
> > Signed-off-by: Petros Angelatos <petrosagg@xxxxxxxxx>
> > Signed-off-by: Pierre-Hugues Husson <phh@xxxxxx>
> > Signed-off-by: Xiao Jia <xiaoj@xxxxxxxxxx>
> > Signed-off-by: Yuan Liu <liuyuan@xxxxxxxxxx>
> > Signed-off-by: Octavian Purdila <tavi.purdila@xxxxxxxxx>
>
> Can we please have this chain cleaned up?
> Please see process/submitting-patches.rst.
>
> > ---
> >  MAINTAINERS                                |   8 +
> >  arch/um/lkl/.gitignore                     |   2 +
> >  arch/um/lkl/Kconfig                        |  95 ++++++
> >  arch/um/lkl/Kconfig.debug                  |   0
> >  arch/um/lkl/configs/lkl_defconfig          |  91 ++++++
> >  arch/um/lkl/include/asm/Kbuild             |  80 +++++
> >  arch/um/lkl/include/asm/bitsperlong.h      |  11 +
> >  arch/um/lkl/include/asm/byteorder.h        |   7 +
> >  arch/um/lkl/include/asm/cpu.h              |  14 +
> >  arch/um/lkl/include/asm/elf.h              |  15 +
> >  arch/um/lkl/include/asm/mutex.h            |   7 +
> >  arch/um/lkl/include/asm/processor.h        |  60 ++++
> >  arch/um/lkl/include/asm/ptrace.h           |  25 ++
> >  arch/um/lkl/include/asm/sched.h            |  23 ++
> >  arch/um/lkl/include/asm/syscalls.h         |  18 ++
> >  arch/um/lkl/include/asm/syscalls_32.h      |  43 +++
> >  arch/um/lkl/include/asm/tlb.h              |  12 +
> >  arch/um/lkl/include/asm/uaccess.h          |  64 ++++
> >  arch/um/lkl/include/asm/unistd_32.h        |  31 ++
> >  arch/um/lkl/include/asm/vmlinux.lds.h      |  14 +
> >  arch/um/lkl/include/asm/xor.h              |   9 +
> >  arch/um/lkl/include/uapi/asm/Kbuild        |   9 +
> >  arch/um/lkl/include/uapi/asm/bitsperlong.h |  13 +
> >  arch/um/lkl/include/uapi/asm/byteorder.h   |  11 +
> >  arch/um/lkl/include/uapi/asm/siginfo.h     |  11 +
> >  arch/um/lkl/include/uapi/asm/swab.h        |  11 +
> >  arch/um/lkl/include/uapi/asm/syscalls.h    | 348 +++++++++++++++++++++
>
> I think this is the first big thing which needs a unification.
>
> In UML we try hard to re-use headers from x86.
> We also have some headers in arch/x86/um/.
>
> LKL should do the same. At least try hard to avoid duplication.
>

In LKL we tried to avoid coupling the kernel build part to a
particular architecture, to make it easier to port it (to different
arches, but as well to other OSes or special environments [1][2]).
That is the main reason for having two build steps, one for kernel
proper, and one for the host. That is why the host part was placed
into tools/lkl to make it clear that is not part of the kernel proper.

I think this is one of the biggest differences between UML and LKL and
it would be helpful to get feedback of what people think of a
potential similar split for UML.

[1] https://www.haiku-os.org/blog/lucian/2010-07-08_booting_lkl_inside_haiku/
[2] https://github.com/lkl/lkl-ntk-driver-poc




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux