On 5/9/19 2:42 PM, Theodore Ts'o wrote: > On Thu, May 09, 2019 at 11:12:12AM -0700, Frank Rowand wrote: >> >> "My understanding is that the intent of KUnit is to avoid booting a kernel on >> real hardware or in a virtual machine. That seems to be a matter of semantics >> to me because isn't invoking a UML Linux just running the Linux kernel in >> a different form of virtualization? >> >> So I do not understand why KUnit is an improvement over kselftest. >> >> ... >> >> What am I missing?" > > One major difference: kselftest requires a userspace environment; it > starts systemd, requires a root file system from which you can load > modules, etc. Kunit doesn't require a root file system; doesn't > require that you start systemd; doesn't allow you to run arbitrary > perl, python, bash, etc. scripts. As such, it's much lighter weight > than kselftest, and will have much less overhead before you can start > running tests. So it's not really the same kind of virtualization. > > Does this help? > > - Ted > I'm back to reply to this subthread, after a delay, as promised. That is the type of information that I was looking for, so thank you for the reply. However, the reply is incorrect. Kselftest in-kernel tests (which is the context here) can be configured as built in instead of as a module, and built in a UML kernel. The UML kernel can boot, running the in-kernel tests before UML attempts to invoke the init process. No userspace environment needed. So exactly the same overhead as KUnit when invoked in that manner.
