OSDev.org

I've checked if this question has been already asked and it seems to me that it wasn't.
There are strictly related articles like:

https://wiki.osdev.org/How_Do_I_Use_A_D ... With_My_OS
https://wiki.osdev.org/Getting_Started# ... nvironment

but my question has a bit different emphasis (not what's possible to use, but what will generate the least configuration overhead).

Thus:
What software stack would you recommend for testing kernels? I mean, I want to test various ready-made kernels downloaded from e.g. github and be immediately able to compile and run them and also go through them line-by-line without need for playing with configuration or at least minimalizing this need as much as it's possible.
Up to this point I successfully used Windows 10 + VirtualBox with Ubuntu 20 Server + qemu installed on Windows + Cygwin from which I connect to Ubuntu 20 Server running on VirtualBox, but I'm starting feeling that such a configuration has some obstacles hindering a programmer to work smoothly.
To name a few such obstacles: Cygwin is just a simulation of Linux environment and as such it doesn't always work as expected. For example redirections can be handled in a weird way. Running some programs like e.g. telnet just does nothing (or at least it seems like that, from what I read I suppose that it can also be related to the way in which redirections and outputting are handled, but it is not essential here). It's true that I mostly use Cygwin to ssh to Ubuntu OS on virtual machine, but sometimes it's just handy to do something local and I'd like to avoid distractions and surprises as much as possible.
I know that I can install GDB on Windows, but this tool is I think much more in Linux/Unix spirit than in Windows spirit and as such I'm also afraid that it'll show some quirks which in turn can cause that I'll think that there's e.g. a problem with a kernel code when in fact it'll be the problem with GDB - Windows interaction.

I tried to run qemu inside VirtualBox, but it had no effect and from I've read it's a bad idea.
Now I think that the best idea might be to install Ubuntu 20 Desktop on the host machine + VirtualBox with Ubuntu 20 Server for building kernels + Simics for running them and watching how they run line-by-line. I'm familiar with qemu so I consider also installing qemu, but not sure if it's a good idea having already installed VirtualBox and Simics - won't they "fight" with each other?
Any suggestions will be appreciated. Thanks in advance!

larrystevens wrote:I want to test various ready-made kernels downloaded from e.g. github and be immediately able to compile and run them and also go through them line-by-line without need for playing with configuration or at least minimalizing this need as much as it's possible.

I'm not sure if this is possible. But it would be interesting to know why you want to do that in the first place? I'm asking because this doesn't sound like kernel development at all. It sounds more like rushing in and rushing out. But maybe I misunderstood you.

And to the several VMs: Of course they contradict each other. Why would one want to run (for example) VirtualBox inside of Qemu? That makes no sense.

I personally use a Ubuntu Linux variant (Xubuntu) with Qemu and OVMF (the UEFI firmware).

Greetings
Peter

larrystevens wrote:What software stack would you recommend for testing kernels? I mean, I want to test various ready-made kernels downloaded from e.g. github and be immediately able to compile and run them

That's just not possible.

There's a kernel testing suite by Google, syzkaller, but that requires a special driver for each kernel.

larrystevens wrote:and also go through them line-by-line without need for playing with configuration or at least minimalizing this need as much as it's possible.

This can be done. Normally you'll need a so called "gdb-stub" in the kernel to do this, but thankfully you can start qemu with "-s -S" flags and then you can connect gdb to the guest VM, no matter what kernel it's running. Then you can load the symbols and debug sections into gdb for that particular kernel (independently to the VM), and you can also see the source code and run through line-by-line.

Cheers,
bzt

Thanks for your responses!

PeterX wrote:But it would be interesting to know why you want to do that in the first place? I'm asking because this doesn't sound like kernel development at all. It sounds more like rushing in and rushing out. But maybe I misunderstood you.

I don't want to write an OS, at least currently.
But I'd like to learn the fundamentals of how kernels work, might be more than fundamentals. Presently I download many small kernels from github, read their code and I try to figure out what this code does. I compile them and observe how they run. I find this a very good method to make familiar with how OS-es work at the practically lowest level possible and it's very enjoyable.
I'm aware that various concepts can be implemented in various kernels differently, so implementations of multi-tasking, virtual memory and all the other things in these small kernels don't have to be the same as in kernels of the widely used operating systems such as Linux or Windows, but first it's interesting nonetheless and second in this way I can find myself answers to a lot (but certainly not all) of my questions that I have after reading tutorials, OS Wiki or other resources. And third these implementations provide information about kernel internals anyway, perhaps even better than implementations in large operating systems.
So short answer to you question is: just for fun and education.

PeterX wrote:And to the several VMs: Of course they contradict each other. Why would one want to run (for example) VirtualBox inside of Qemu? That makes no sense.

I meant Qemu inside VirtualBox. The reason for which I prefer to do it this way is as from https://qemu.weilnetz.de/w64/: "QEMU for Windows is experimental software and might contain even serious bugs, so use the binaries at your own risk" and my host system is Windows.

bzt wrote:This can be done. Normally you'll need a so called "gdb-stub" in the kernel to do this, but thankfully you can start qemu with "-s -S" flags and then you can connect gdb to the guest VM, no matter what kernel it's running. Then you can load the symbols and debug sections into gdb for that particular kernel (independently to the VM), and you can also see the source code and run through line-by-line

I'm aware of that method, although I don't have detailed knowledge of it yet. I tried it but with no success, that is it was possible to run kernel step-by-step but like nothing happened. But I think I'll create a new thread for it if I doesn't succeed with it.

bzt wrote:There's a kernel testing suite by Google, syzkaller, but that requires a special driver for each kernel.

As I understand this driver would need to be provided by the given kernel itself?

Remark: as for now, after installing a graphical environment in my Ubuntu on VirtualBox I can successfully run various kernels in QEMU (installed in this Ubuntu). I'm aware that such a configuration is fragile, but at most I won't be able to run some kernel.
I'm interested, though: does various virtualizers/emulators in practice conflict with each other when installed side-by-side?

larrystevens wrote:

bzt wrote:There's a kernel testing suite by Google, syzkaller, but that requires a special driver for each kernel.

As I understand this driver would need to be provided by the given kernel itself?

Yes. The documentation explains it pretty well.

larrystevens wrote:I'm aware of that method, although I don't have detailed knowledge of it yet. I tried it but with no success

Take a look at my Makefile. I run make debug in one terminal window (which starts the VM), and make gdb in another (where I can use the gdb prompt).

larrystevens wrote:I'm interested, though: does various virtualizers/emulators in practice conflict with each other when installed side-by-side?

That depends. For hardware accelerated solutions, like kvm you can't use multiple kernel modules for different architectures at once on the host (kvm is used by both qemu and VirtualBox). Software emulation is slow, but it's guaranteed not to conflict with each other (like bochs for example).

Cheers,
bzt