<snip> > > And like I said before, that decision will frame everything else. I > > really don't think we can make significant progress here without having > > decided whether this is possible. > > > > Perhaps UML *can* become a "special case" of LKL, with a special API > > function (that's not part of the syscall surface) to "boot(cmdline)" or > > something. But if it can't, and has to remain as separated as the two > > are today, I would argue we're better off just not calling them the same > > architecture. > > I agree with this if the unification has all completed. > I tought a lot about this and I agree with Johannes that if we want to unity UML and LKL we should start with the hard parts. I am also starting to think that it is unlikely to be able to merge the two "nicely" and that we should probably turn this on its head and start with reworking UML towards the LKL features. We will end up re-implementing *some* of the LKL concepts from scratch in UML but I think at this point this is unavoidable. Here are my thoughts on a very rough plan for doing that: Milestone 1: LKL lib on top of UML * Kernel - Host build split Build UML as a relocatable object using the UML’s kernel linker script. Move the ptrace and other well isolated os code out of arch/um to tools/um (or maybe start directly with tools/lkl?) Use standard host toolchain to create a static library stripped of the ptrace code. Use standard host toolchain to build the main UML executable. Add library init API that creates the UML kernel process and starts UML. * System calls APIs Add new system call interface dbased on fd irq. Use the LKL scripts to export the required headers to create system calls APIs that use the UML system calls infrastructure. Keep the underlying host and driver operations (threads, irqs, etc.) as they are now in UML. * Boot test Port the LKL boot test to verify that we are able to programatically issue system calls. Milestone 2: add virtio disk support * Export asm/io.h operations to host/os. Create IO access operations and redirect them to weak os_ variants that use the current UML implementation. * Add the LKL IO access layer including generic virtio handling and the virtio block device code. * Port LKL disk test and disk apps (lklfuse, fs2tar, cptofs) Milestone 3: new arch ports * Abstrac the system call / IRQ mode the move the implementation to host * Abstract the thread model and move the implementation to host * Add LKL thread model and LKL ports Thanks, Tavi
