Hi,
while developing my kernel I often screw up. No surprise there. But esspecially early in the game that means the system just crashes. You have no debugger, printk often doesn't work and so on.
So when possible I've written code under linux as normal programs. I've written little wrapper functions that map my kernel functions unto the usual C functions. For example I have a kmalloc() that just calls malloc(). That way I can for example write and debug the code for a list or heap using gdb, valgrind, printf and so on.
Now I'm wondering if one couldn't take this a step further. With mmap() and mprotect() you have control over virtual memory and page mapping. With that you can simulate an MMU. Depending on how low level you want to get you could even provide a shadow page table and catch all write accesses to it and emulate the change with mmap()/mprotect(). Or more highlevel you could have map_page(), unmap_page() or something.
You can implement timer interrupts with alarm() and signal handling for multitasking.
Obviously keyboard input and console output is trivial too.
I wonder if one couldn't implement the XEN paravirtual API with a little bit of C as the lowest level and a collection of higher level modules with common interfaces. Like a kalloc()/kfree() in a memory module.
That way people could pick prooven modules and test their code against it when they experience problems running it in their kernel directly. Think how much easier writing the console driver for your own kernel would be if you could printf() debug info. Or your own printk() function with printf() debugs whats going on?
What do you think? Anyone interested?
MfG
Mrvn
Testbed Idea: Simulate a kernels environment with C/posix
Testbed Idea: Simulate a kernels environment with C/posix
Life - Don't talk to me about LIFE!
So long and thanks for all the fish.
So long and thanks for all the fish.
Well, typically people write a print command, and display it to the screen, and put a hang in there to check states, or something that is becoming very common due to simplicity and useability is a simple serial port driver and directing the print statements to their. This way, in bochs you can log straight to serial.txt, which means you can have more than 1 page of info dislpayed, if the kernel hands, the data is not lost, and on a real PC if you have a listening PC you can log what is actually going on also. While running tests in a 'normal' environment first is a good thing, I don't know how crazy you really want to get, because once you're kernel is past a certain state (aka, stable enough to debug with), you probably won't waste your time anymore, so how low level you want to get with the wrapper really depends on how bad your debug routines in your kernel are, and how hard you find it to track down bugs. If you need to track bugs/work on code that keeps triple faulting, write a serial port driver to log the calls, etc with. If you get really deep in, you may even want to look into writing a logging system that will track function calls, source files, and line numbers in the kernel, so you can see what functions were being called before the crash, and have a nice way to disable (maybe a #define of sorts) logging so you can compile in run-mode and debug-mode, or possibly a switch/option so you can enable/disable it while running the kernel (when you get to input, etc). I would worry more about debugging in the kernel, and less in a virtual environment, because once you get your kernel far enough along, you will have wasted all that time on the virtual environment, and you're kernel still won't be able to be debugged easily once things get really complicated (like tracking down a function that is getting interrupted and blasting a register or the interrupt changes some data that it is also trying to use and triple faulting).
Running simulations of OS pieces is all very nice, but what do you do if the simulator has a bug in it? I basically agree with Ready4Dis -- the best emulator of all is real hardware, and to use it properly you've got to get some exception handler / debugger methodology running in your OS, early on.
To do high-level simulations properly for your algorithms, you need to have the ideas for the algorithms first. Some of those ideas you will have before you start coding your OS. Many of those will turn out to be bad ideas, and will not pan out. Most of your good ideas you will actually get while you write code for the other parts of the OS. So sitting there and hacking your way through the problems in your OS is often a good thing.
To do high-level simulations properly for your algorithms, you need to have the ideas for the algorithms first. Some of those ideas you will have before you start coding your OS. Many of those will turn out to be bad ideas, and will not pan out. Most of your good ideas you will actually get while you write code for the other parts of the OS. So sitting there and hacking your way through the problems in your OS is often a good thing.