From: Richard Weinberger <richard.weinberger@gmail.com> To: Johannes Berg <johannes@sipsolutions.net> Cc: Hajime Tazaki <thehajime@gmail.com>, linux-um <linux-um@lists.infradead.org>, Linux-Arch <linux-arch@vger.kernel.org>, Levente Kurusa <levex@linux.com>, Matthieu Coudron <mattator@gmail.com>, Conrad Meyer <cem@freebsd.org>, Octavian Purdila <tavi.purdila@gmail.com>, Jens Staal <staal1978@gmail.com>, Motomu Utsumi <motomuman@gmail.com>, Lai Jiangshan <jiangshanlai@gmail.com>, Akira Moroo <retrage01@gmail.com>, Petros Angelatos <petrosagg@gmail.com>, "Edison M . Castro" <edisonmcastro@hotmail.com>, Xiao Jia <xiaoj@google.com>, Mark Stillwell <mark@stillwell.me>, linux-kernel-library@freelists.org, Patrick Collins <pscollins@google.com>, Pierre-Hugues Husson <phh@phh.me>, Michael Zimmermann <sigmaepsilon92@gmail.com>, Luca Dariz <luca.da> Subject: Re: [RFC v4 02/25] um lkl: architecture skeleton for Linux kernel library Date: Tue, 31 Mar 2020 00:12:38 +0200 [thread overview] Message-ID: <CAFLxGvyFqXZSmMcD_=o81AHLzdM_u2iH8h412w7VZrxON7Ohig@mail.gmail.com> (raw) In-Reply-To: <a84f3d7bcddbaa6125349c4bcdec6e3e07d6b783.camel@sipsolutions.net> Johannes, Hajime, On Mon, Mar 30, 2020 at 11:53 PM Johannes Berg <johannes@sipsolutions.net> wrote: > > On Mon, 2020-03-30 at 23:45 +0900, Hajime Tazaki wrote: > > From: Octavian Purdila <tavi.purdila@gmail.com> > > > > 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. > > Can you elaborate what the plan is here? > > I mean, you're not actually "unifying" anything with ARCH=um, you're > just basically splitting ARCH=um into ARCH=um-um and ARCH=um-lkl or > something. Is there much point? > > Even the basic underlying building blocks are _very_ different, e.g. in > UML the host interface is just a bunch of functions that must be > implemented (os_*()), while you have a "struct lkl_host_operations". If > we can't even unify at that trivial level, is there any point in it at > all? I'm not even really sure what those ops are used for - are all of > those things that the *application* using LKL necessarily must provide? > > Similarly with the IRQ routing mechanism - two completely different > concepts. Where's the "unifying"? > > Ultimately, I can see two ways this goes: > > 1) We give up, and get ARCH=lkl, sharing just (some of) the drivers > while moving them into the right drivers/somewhere/ place. Even that > looks somewhat awkward looking at the later patches in this set, but > seems like that at *least* should be done. Yeah, this would be a goal. UML and LKL are quite different but they should share at least their userspace drivers. I also don't mind if we don't share every driver at the beginning but it should be a feasible goal for the future. > 2) Ideally, instead, we actually unify: LKL grows support for userspace > processes using UML infrastructure, the "in-kernel" IRQ mechanisms > are unified, UML stuff moves into lkl-ops, and the UML binary > basically becomes a user of the LKL library to start everything up. > There may be some bits remaining that are just not interesting (e.g. > some drivers you don't care about would continue to make direct calls > to the user side instead of lkl-ops, and then they're just not > compatible with lkl, only with the uml special case of lkl), but then > things are clean. A few months ago I though this is doable but now I'm not so sure anymore. > > Now, of course it seems like (2) would actually be better - LKL would > actually get support for userspace processes using UML's tricks, most of > the code is unified, and even LKL's users can take advantage of new > things. At the same time, all of the duplication is avoided. > > However, I just don't know if it's actually _possible_ to do that > though. Conceptually, it seems like it should be - why shouldn't a > library be able to spawn other userspace processes - I mean, it's not > really in the model that LKL really _wants_ since it's supposed to offer > the syscall API, but you could make a "bool run_normal_init" or > something in the lkl-ops for the user of the library to determine what > should happen, right? > > However, there clearly are huge differences between LKL and UML in all > respects, and I don't know if this wouldn't conflict with the library > model, e.g. there may be linker issues etc. Or maybe the specific UML > interrupt handling is required in UML and cannot be done in LKL (but > then perhaps it could be put into the hypothetical UML-application vs. > UML-the-LKL-library?) > > > Ultimately, personally I think it's going to have to be one or the other > of those two options though, I don't really see much value in what > you're doing here in the patchset now. This way just messes up > everything, it's not clear what's UML and what's LKL, and they're > intertwined with ifdefs everywhere; just look at where you have to add > ifdefs in patch 23 - how would anyone later understand which part gets > compiled for which of them? > > johannes > > PS: actually having something like lkl-ops in UML would've been nice > also for my "time-travel" work, since it neatly abstracts the timers > out. I do wonder a bit about the overhead of jumping through function > pointers all the time though, it may be worth rethinking that overall > anyway! Agreed. UML can also learn from LKL. :-) -- Thanks, //richard
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard.weinberger@gmail.com> To: Johannes Berg <johannes@sipsolutions.net> Cc: Hajime Tazaki <thehajime@gmail.com>, linux-um <linux-um@lists.infradead.org>, Linux-Arch <linux-arch@vger.kernel.org>, Levente Kurusa <levex@linux.com>, Matthieu Coudron <mattator@gmail.com>, Conrad Meyer <cem@freebsd.org>, Octavian Purdila <tavi.purdila@gmail.com>, Jens Staal <staal1978@gmail.com>, Motomu Utsumi <motomuman@gmail.com>, Lai Jiangshan <jiangshanlai@gmail.com>, Akira Moroo <retrage01@gmail.com>, Petros Angelatos <petrosagg@gmail.com>, "Edison M . Castro" <edisonmcastro@hotmail.com>, Xiao Jia <xiaoj@google.com>, Mark Stillwell <mark@stillwell.me>, linux-kernel-library@freelists.org, Patrick Collins <pscollins@google.com>, Pierre-Hugues Husson <phh@phh.me>, Michael Zimmermann <sigmaepsilon92@gmail.com>, Luca Dariz <luca.dariz@gmail.com>, Yuan Liu <liuyuan@google.com> Subject: Re: [RFC v4 02/25] um lkl: architecture skeleton for Linux kernel library Date: Tue, 31 Mar 2020 00:12:38 +0200 [thread overview] Message-ID: <CAFLxGvyFqXZSmMcD_=o81AHLzdM_u2iH8h412w7VZrxON7Ohig@mail.gmail.com> (raw) Message-ID: <20200330221238.L7VG2axO2UQBs5cs2BSaYt9skQMjFjIjJaCyt2Bf06s@z> (raw) In-Reply-To: <a84f3d7bcddbaa6125349c4bcdec6e3e07d6b783.camel@sipsolutions.net> Johannes, Hajime, On Mon, Mar 30, 2020 at 11:53 PM Johannes Berg <johannes@sipsolutions.net> wrote: > > On Mon, 2020-03-30 at 23:45 +0900, Hajime Tazaki wrote: > > From: Octavian Purdila <tavi.purdila@gmail.com> > > > > 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. > > Can you elaborate what the plan is here? > > I mean, you're not actually "unifying" anything with ARCH=um, you're > just basically splitting ARCH=um into ARCH=um-um and ARCH=um-lkl or > something. Is there much point? > > Even the basic underlying building blocks are _very_ different, e.g. in > UML the host interface is just a bunch of functions that must be > implemented (os_*()), while you have a "struct lkl_host_operations". If > we can't even unify at that trivial level, is there any point in it at > all? I'm not even really sure what those ops are used for - are all of > those things that the *application* using LKL necessarily must provide? > > Similarly with the IRQ routing mechanism - two completely different > concepts. Where's the "unifying"? > > Ultimately, I can see two ways this goes: > > 1) We give up, and get ARCH=lkl, sharing just (some of) the drivers > while moving them into the right drivers/somewhere/ place. Even that > looks somewhat awkward looking at the later patches in this set, but > seems like that at *least* should be done. Yeah, this would be a goal. UML and LKL are quite different but they should share at least their userspace drivers. I also don't mind if we don't share every driver at the beginning but it should be a feasible goal for the future. > 2) Ideally, instead, we actually unify: LKL grows support for userspace > processes using UML infrastructure, the "in-kernel" IRQ mechanisms > are unified, UML stuff moves into lkl-ops, and the UML binary > basically becomes a user of the LKL library to start everything up. > There may be some bits remaining that are just not interesting (e.g. > some drivers you don't care about would continue to make direct calls > to the user side instead of lkl-ops, and then they're just not > compatible with lkl, only with the uml special case of lkl), but then > things are clean. A few months ago I though this is doable but now I'm not so sure anymore. > > Now, of course it seems like (2) would actually be better - LKL would > actually get support for userspace processes using UML's tricks, most of > the code is unified, and even LKL's users can take advantage of new > things. At the same time, all of the duplication is avoided. > > However, I just don't know if it's actually _possible_ to do that > though. Conceptually, it seems like it should be - why shouldn't a > library be able to spawn other userspace processes - I mean, it's not > really in the model that LKL really _wants_ since it's supposed to offer > the syscall API, but you could make a "bool run_normal_init" or > something in the lkl-ops for the user of the library to determine what > should happen, right? > > However, there clearly are huge differences between LKL and UML in all > respects, and I don't know if this wouldn't conflict with the library > model, e.g. there may be linker issues etc. Or maybe the specific UML > interrupt handling is required in UML and cannot be done in LKL (but > then perhaps it could be put into the hypothetical UML-application vs. > UML-the-LKL-library?) > > > Ultimately, personally I think it's going to have to be one or the other > of those two options though, I don't really see much value in what > you're doing here in the patchset now. This way just messes up > everything, it's not clear what's UML and what's LKL, and they're > intertwined with ifdefs everywhere; just look at where you have to add > ifdefs in patch 23 - how would anyone later understand which part gets > compiled for which of them? > > johannes > > PS: actually having something like lkl-ops in UML would've been nice > also for my "time-travel" work, since it neatly abstracts the timers > out. I do wonder a bit about the overhead of jumping through function > pointers all the time though, it may be worth rethinking that overall > anyway! Agreed. UML can also learn from LKL. :-) -- Thanks, //richard
next prev parent reply other threads:[~2020-03-30 22:12 UTC|newest] Thread overview: 251+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-05 7:30 [RFC v3 00/26] Unifying LKL into UML Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 01/26] asm-generic: atomic64: allow using generic atomic64 on 64bit platforms Hajime Tazaki 2020-02-05 9:34 ` Peter Zijlstra 2020-02-05 12:24 ` Octavian Purdila 2020-02-05 12:29 ` Anton Ivanov 2020-02-05 12:49 ` Peter Zijlstra 2020-02-05 14:00 ` Octavian Purdila 2020-02-05 17:13 ` Peter Zijlstra 2020-02-07 12:32 ` Octavian Purdila [not found] ` <cover.1580882335.git.thehajime-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2020-02-05 7:30 ` [RFC v3 02/26] arch: add __SYSCALL_DEFINE_ARCH Hajime Tazaki 2020-02-05 7:30 ` Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 03/26] um lkl: architecture skeleton for Linux kernel library Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 04/26] um lkl: host interface Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 05/26] um lkl: memory handling Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 06/26] um lkl: kernel threads support Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 07/26] um lkl: interrupt support Hajime Tazaki 2020-02-05 10:47 ` Anton Ivanov 2020-02-05 14:46 ` Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 08/26] um lkl: system call interface and application API Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 09/26] um lkl: timers, time and delay support Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 10/26] um lkl: basic kernel console support Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 11/26] um lkl: initialization and cleanup Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 12/26] um lkl: plug in the build system Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 13/26] lkl tools: skeleton for host side library Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 14/26] lkl tools: host lib: add utilities functions Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 15/26] lkl tools: host lib: filesystem helpers Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 16/26] lkl tools: host lib: networking helpers Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 17/26] lkl tools: host lib: posix host operations Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 18/26] lkl tools: add test programs Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 19/26] lkl tools: cptofs that reads/writes to/from a filesystem image Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 20/26] lkl tools: fs2tar that converts a filesystem image to tar Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 21/26] lkl tools: add lklfuse Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 22/26] um lkl: add documentation Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 23/26] um lkl: add CI scripts to conduct regression tests Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 24/26] um lkl: add UML network driver for lkl Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 25/26] um lkl: add UML block device driver (ubd) " Hajime Tazaki 2020-02-05 7:30 ` [RFC v3 26/26] um: fix clone flags to be familar with valgrind Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 00/25] Unifying LKL into UML Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 01/25] arch: add __SYSCALL_DEFINE_ARCH Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 02/25] um lkl: architecture skeleton for Linux kernel library Hajime Tazaki 2020-03-30 21:53 ` Johannes Berg 2020-03-30 22:12 ` Richard Weinberger [this message] 2020-03-30 22:12 ` Richard Weinberger 2020-03-31 7:08 ` Hajime Tazaki 2020-03-31 20:16 ` Johannes Berg 2020-04-02 6:44 ` Hajime Tazaki 2020-04-07 19:25 ` Octavian Purdila 2020-04-07 19:25 ` Octavian Purdila 2020-03-30 14:45 ` [RFC v4 03/25] um lkl: host interface Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 04/25] um lkl: memory handling Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 05/25] um lkl: kernel threads support Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 06/25] um lkl: interrupt support Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 07/25] um lkl: system call interface and application API Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 08/25] um lkl: timers, time and delay support Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 09/25] um lkl: basic kernel console support Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 10/25] um lkl: initialization and cleanup Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 11/25] um lkl: plug in the build system Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 12/25] lkl tools: skeleton for host side library Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 13/25] lkl tools: host lib: add utilities functions Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 14/25] lkl tools: host lib: filesystem helpers Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 15/25] lkl tools: host lib: networking helpers Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 16/25] lkl tools: host lib: posix host operations Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 17/25] lkl tools: add test programs Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 18/25] lkl tools: cptofs that reads/writes to/from a filesystem image Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 19/25] lkl tools: fs2tar that converts a filesystem image to tar Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 20/25] lkl tools: add lklfuse Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 21/25] um lkl: add documentation Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 22/25] um lkl: add CI scripts to conduct regression tests Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 23/25] um lkl: add UML network driver for lkl Hajime Tazaki 2020-03-30 21:31 ` Johannes Berg 2020-03-31 2:38 ` Hajime Tazaki 2020-03-31 19:52 ` Johannes Berg 2020-03-30 14:45 ` [RFC v4 24/25] um lkl: add UML block device driver (ubd) " Hajime Tazaki 2020-03-30 14:45 ` [RFC v4 25/25] um: fix clone flags to be familiar with valgrind Hajime Tazaki 2020-07-02 14:06 ` [RFC v5 00/21] Unifying LKL into UML Hajime Tazaki 2020-07-02 14:06 ` [RFC v5 01/21] um: split build in kernel and host parts Hajime Tazaki 2020-09-21 16:01 ` Anton Ivanov 2020-09-21 22:27 ` Hajime Tazaki 2020-07-02 14:06 ` [RFC v5 02/21] um: add os init and exit calls Hajime Tazaki 2020-07-02 14:06 ` [RFC v5 03/21] um: move arch/um/os-Linux dir to tools/um/uml Hajime Tazaki 2020-07-02 14:06 ` [RFC v5 04/21] um: host: implement os_initcalls and os_exitcalls Hajime Tazaki 2020-07-02 14:06 ` [RFC v5 05/21] um: move arch/x86/um/os-Linux to tools/um/uml/ Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 06/21] scritps: um: suppress warnings if SRCARCH=um Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 07/21] um: extend arch_switch_to for alternate SUBARCH Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 08/21] um: add nommu mode for UML library mode Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 09/21] um: nommu: host interface Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 10/21] um: nommu: memory handling Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 11/21] um: nommu: kernel thread support Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 12/21] um: nommu: system call interface and application API Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 13/21] um: nommu: basic console support Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 14/21] um: nommu: initialization and cleanup Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 15/21] um: nommu: integrate with irq infrastructure of UML Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 16/21] um: nommu: plug in the build system Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 17/21] um: host: add nommu build for ARCH=um Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 18/21] um: host: add utilities functions Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 19/21] um: host: posix host operations Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 20/21] um: host: add test programs Hajime Tazaki 2020-07-02 14:07 ` [RFC v5 21/21] um: nommu: add block device support of UML Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 00/21] Unifying LKL into UML Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 01/21] um: split build in kernel and host parts Hajime Tazaki 2020-09-24 7:33 ` Anton Ivanov 2020-09-24 8:26 ` Hajime Tazaki 2020-09-24 8:37 ` Anton Ivanov 2020-09-24 7:36 ` Anton Ivanov 2020-09-24 8:13 ` Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 02/21] um: add os init and exit calls Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 03/21] um: move arch/um/os-Linux dir to tools/um/uml Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 04/21] um: host: implement os_initcalls and os_exitcalls Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 05/21] um: move arch/x86/um/os-Linux to tools/um/uml/ Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 06/21] scritps: um: suppress warnings if SRCARCH=um Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 07/21] um: extend arch_switch_to for alternate SUBARCH Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 08/21] um: add nommu mode for UML library mode Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 09/21] um: nommu: host interface Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 10/21] um: nommu: memory handling Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 11/21] um: nommu: kernel thread support Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 12/21] um: nommu: system call interface and application API Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 13/21] um: nommu: basic console support Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 14/21] um: nommu: initialization and cleanup Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 15/21] um: nommu: integrate with irq infrastructure of UML Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 16/21] um: nommu: plug in the build system Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 17/21] um: host: add nommu build for ARCH=um Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 18/21] um: host: add utilities functions Hajime Tazaki 2020-09-24 7:12 ` [RFC v6 19/21] um: host: posix host operations Hajime Tazaki 2020-09-24 7:13 ` [RFC v6 20/21] um: host: add test programs Hajime Tazaki 2020-09-24 7:13 ` [RFC v6 21/21] um: nommu: add block device support of UML Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 00/21] Unifying LKL into UML Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 01/21] um: split build in kernel and host parts Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 02/21] um: add os init and exit calls Hajime Tazaki 2020-10-07 15:13 ` Johannes Berg 2020-10-08 13:18 ` Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 03/21] um: move arch/um/os-Linux dir to tools/um/uml Hajime Tazaki 2020-10-07 15:20 ` Johannes Berg 2020-10-08 17:48 ` Octavian Purdila 2020-10-08 19:46 ` Johannes Berg 2020-10-08 20:53 ` Octavian Purdila 2020-10-09 15:59 ` Johannes Berg 2020-10-06 9:44 ` [RFC v7 04/21] um: host: implement os_initcalls and os_exitcalls Hajime Tazaki 2020-10-07 15:22 ` Johannes Berg 2020-10-08 13:16 ` Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 05/21] um: move arch/x86/um/os-Linux to tools/um/uml/ Hajime Tazaki 2020-10-07 15:23 ` Johannes Berg 2020-10-06 9:44 ` [RFC v7 06/21] scritps: um: suppress warnings if SRCARCH=um Hajime Tazaki 2020-10-07 15:24 ` Johannes Berg 2020-10-09 1:13 ` Hajime Tazaki 2020-10-09 16:00 ` Johannes Berg 2020-10-06 9:44 ` [RFC v7 07/21] um: extend arch_switch_to for alternate SUBARCH Hajime Tazaki 2020-10-07 15:25 ` Johannes Berg 2020-10-09 1:24 ` Hajime Tazaki 2020-10-09 16:02 ` Johannes Berg 2020-10-06 9:44 ` [RFC v7 08/21] um: add nommu mode for UML library mode Hajime Tazaki 2020-10-07 15:44 ` Johannes Berg 2020-10-09 3:38 ` Hajime Tazaki 2020-10-09 16:06 ` Johannes Berg 2020-10-20 8:44 ` Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 09/21] um: nommu: host interface Hajime Tazaki 2020-10-07 15:45 ` Johannes Berg 2020-10-08 18:10 ` Octavian Purdila 2020-10-06 9:44 ` [RFC v7 10/21] um: nommu: memory handling Hajime Tazaki 2020-10-07 15:47 ` Johannes Berg 2020-10-08 18:07 ` Octavian Purdila 2020-10-06 9:44 ` [RFC v7 11/21] um: nommu: kernel thread support Hajime Tazaki 2020-10-07 18:57 ` Johannes Berg 2020-10-08 18:54 ` Octavian Purdila 2020-10-08 19:39 ` Johannes Berg 2020-10-08 20:25 ` Octavian Purdila 2020-10-06 9:44 ` [RFC v7 12/21] um: nommu: system call interface and application API Hajime Tazaki 2020-10-07 19:05 ` Johannes Berg 2020-10-08 19:03 ` Octavian Purdila 2020-10-08 19:40 ` Johannes Berg 2020-10-06 9:44 ` [RFC v7 13/21] um: nommu: basic console support Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 14/21] um: nommu: initialization and cleanup Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 15/21] um: nommu: integrate with irq infrastructure of UML Hajime Tazaki 2020-10-07 19:09 ` Johannes Berg 2020-10-06 9:44 ` [RFC v7 16/21] um: nommu: plug in the build system Hajime Tazaki 2020-10-07 19:20 ` Johannes Berg 2020-10-09 7:40 ` Hajime TAZAKI 2020-10-06 9:44 ` [RFC v7 17/21] um: host: add nommu build for ARCH=um Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 18/21] um: host: add utilities functions Hajime Tazaki 2020-10-07 14:53 ` Anton Ivanov 2020-10-07 15:02 ` Johannes Berg 2020-10-07 15:03 ` Johannes Berg 2020-10-07 15:10 ` Anton Ivanov 2020-10-08 12:52 ` Hajime Tazaki 2020-10-08 19:19 ` Octavian Purdila 2020-10-08 12:53 ` Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 19/21] um: host: posix host operations Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 20/21] um: host: add test programs Hajime Tazaki 2020-10-07 19:23 ` Johannes Berg 2020-10-09 6:24 ` Hajime Tazaki 2020-10-06 9:44 ` [RFC v7 21/21] um: nommu: add block device support of UML Hajime Tazaki 2020-10-07 14:17 ` Anton Ivanov 2020-10-08 12:13 ` Hajime Tazaki 2020-10-07 13:30 ` [RFC v7 00/21] Unifying LKL into UML Anton Ivanov 2020-10-08 12:12 ` Hajime Tazaki 2020-10-08 12:50 ` Anton Ivanov 2020-10-08 17:13 ` Octavian Purdila 2020-10-08 17:18 ` Anton Ivanov 2020-10-08 17:24 ` Octavian Purdila 2021-01-20 2:27 ` [RFC v8 00/20] " Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 01/20] um: split build in kernel and host parts Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 02/20] um: move arch/um/os-Linux dir to tools/um/uml Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 03/20] um: move arch/x86/um/os-Linux to tools/um/uml/ Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 04/20] um: implement os_initcalls and os_exitcalls Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 05/20] um: extend arch_switch_to for alternate SUBARCH Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 06/20] um: add UML library mode Hajime Tazaki 2021-03-14 16:49 ` Johannes Berg 2021-03-16 1:17 ` Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 07/20] um: lkl: host interface Hajime Tazaki 2021-03-14 16:50 ` Johannes Berg 2021-03-16 1:17 ` Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 08/20] um: lkl: memory handling Hajime Tazaki 2021-03-14 16:53 ` Johannes Berg 2021-03-16 1:18 ` Hajime Tazaki 2021-03-16 21:31 ` Johannes Berg 2021-03-18 0:12 ` Hajime Tazaki 2021-03-18 8:00 ` Johannes Berg 2021-01-20 2:27 ` [RFC v8 09/20] um: lkl: kernel thread support Hajime Tazaki 2021-03-14 17:01 ` Johannes Berg 2021-03-16 1:18 ` Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 10/20] um: lkl: system call interface and application API Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 11/20] um: lkl: basic console support Hajime Tazaki 2021-03-14 20:42 ` Johannes Berg 2021-03-16 1:19 ` Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 12/20] um: lkl: initialization and cleanup Hajime Tazaki 2021-03-14 20:40 ` Johannes Berg 2021-03-16 1:19 ` Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 13/20] um: lkl: integrate with irq infrastructure of UML Hajime Tazaki 2021-03-14 20:45 ` Johannes Berg 2021-03-16 1:20 ` Hajime Tazaki 2021-03-16 21:36 ` Johannes Berg 2021-01-20 2:27 ` [RFC v8 14/20] um: lkl: plug in the build system Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 15/20] um: host: add library mode build for ARCH=um Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 16/20] um: host: add utilities functions Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 17/20] um: host: posix host operations Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 18/20] selftests/um: lkl: add test programs for library mode of UML Hajime Tazaki 2021-01-20 2:27 ` [RFC v8 19/20] um: lkl: add block device support " Hajime Tazaki 2021-03-14 20:37 ` Johannes Berg 2021-03-16 1:19 ` Hajime Tazaki 2021-03-16 21:32 ` Johannes Berg 2021-03-17 14:19 ` Octavian Purdila 2021-03-17 14:28 ` Johannes Berg 2021-03-18 0:15 ` Hajime Tazaki 2021-03-18 0:43 ` Octavian Purdila 2021-01-20 2:27 ` [RFC v8 20/20] um: lkl: add documentation Hajime Tazaki 2021-03-14 21:03 ` [RFC v8 00/20] Unifying LKL into UML Johannes Berg 2021-03-16 1:17 ` Hajime Tazaki 2021-03-16 21:29 ` Johannes Berg 2021-03-17 14:03 ` Octavian Purdila 2021-03-17 14:24 ` Johannes Berg 2021-03-18 14:17 ` Hajime Tazaki 2021-03-18 16:28 ` Johannes Berg
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAFLxGvyFqXZSmMcD_=o81AHLzdM_u2iH8h412w7VZrxON7Ohig@mail.gmail.com' \ --to=richard.weinberger@gmail.com \ --cc=cem@freebsd.org \ --cc=edisonmcastro@hotmail.com \ --cc=jiangshanlai@gmail.com \ --cc=johannes@sipsolutions.net \ --cc=levex@linux.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel-library@freelists.org \ --cc=linux-um@lists.infradead.org \ --cc=mark@stillwell.me \ --cc=mattator@gmail.com \ --cc=motomuman@gmail.com \ --cc=petrosagg@gmail.com \ --cc=phh@phh.me \ --cc=pscollins@google.com \ --cc=retrage01@gmail.com \ --cc=sigmaepsilon92@gmail.com \ --cc=staal1978@gmail.com \ --cc=tavi.purdila@gmail.com \ --cc=thehajime@gmail.com \ --cc=xiaoj@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).