On Fri, Nov 8, 2019 at 11:13 AM Anton Ivanov <anton.ivanov@xxxxxxxxxxxxxxxxxx> wrote: > <snip> Hi Anton, > I am reading the patch-set and I have a recurring question as I read it. > It applies to IRQ, mmap IO, timers, devices, etc > > The question is: "What is the unerlying req to replace the existing UML > code for the library". > > F.e timers in UML have been moved to an underlying POSIX timers call now > and that can probably work on any system that offers it. If there is > some presentation/documentation/etc material which I can read which goes > through the actual choices it will be very helpful. > This (old) paper should help with some of the rationale and design decision behind LKL: https://www.researchgate.net/publication/224164682_LKL_The_Linux_kernel_library > The same question applies the other way around too. I like the hostops > approach, we can probably adopt some of that in UML proper to make it > more portable and easier to have alternative implementations for the > underlying host side operations. > The host ops part is not properly explained in the paper as it evolved over time (they are called native operations there), so I will try to give a high level overview here. In order to make it easier to compile LKL applications for different targets (OSes, architectures, user/kernel) we decided to use a two step build process: a kernel build and a host target (+apps) build. This helped us reduce intrusions in the kernel build system while allowing to support the various requirements a host target has. As part of the first step a lkl.o object and a set of processed kernel uabi headers (to avoid conflicts with host Linux kernel headers) are generated. These are then use to build a library (liblkl.so) for a specific target. Here is where host ops are compiled in together with the lkl.o object. This is the reason for the split between arch/lkl (kernel) and tools/lkl (host target). I think this build split is the biggest challenge in integrating LKL with UML and I think once this is resolved it will be much easier to merge the rest. I am curios to learn what you think about such a split build for UML and if there are any low hanging fruits we could start from. Thanks, Tavi
