Johannes, Hajime, On Mon, Mar 30, 2020 at 11:53 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Mon, 2020-03-30 at 23:45 +0900, Hajime Tazaki 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. > > 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
