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.