OSDev.org

I've already implemented multitasking and a simple form of IPC in my kernel. I'm trying to set up a simple system under it with a shell and console driver. The way it works is that the shell sends a signal (sort of like *nix signals, but more like a small message) to the console driver. The console driver then asks the kernel to map a page of memory from the shell's address space (where the buffer to be printed is) to a location into the driver's own address space. The proper memory location is then read directly from this remapping and printed to the screen.

So far, this has been working fine, as long as the buffer is a global variable (i.e. in the data section). However, if I allocate the buffer on the stack as a local variable, the driver prints out either nothing or garbage. I have compensated for the buffer not being page aligned, and that is not the problem. I also tried enabling write-through caching and disabling caching, both on the pages in the stack and on the system as a whole (by setting flags on CR3). I checked the addresses being passed to the driver, and they are also correct. There are no compiler optimizations - optimizing breaks both cases. Any idea what the problem could be?

It sounds like rather a brittle method of doing things, anyway. Isn't your kernel mapped into all process address spaces?

It is, but I'm trying to do a microkernel, so drivers need to send large amount of information. However, I see your point - I think I'm going to have a system call for the kernel to do the copying of data instead.

NickJohnson wrote:Any idea what the problem could be?

Wild guess: buffer overrun?

Try surrounding the buffer with "guards".
Then make sure the guard variables around the buffer don't get changed. If they do, the kernel wrote too much and corrupted the stack.

manonthemoon wrote:

NickJohnson wrote:Any idea what the problem could be?

Wild guess: buffer overrun?

Try surrounding the buffer with "guards".

Code: Select all

int x = 0xDEADBEEF;
char buffer[100];
int y = 0xDEADBEEF;

Then make sure the guard variables around the buffer don't get changed. If they do, the kernel wrote too much and corrupted the stack.

This is a bad idea. Most compilers won't guarantee that the values are pushed in order.

manonthemoon wrote:

NickJohnson wrote:Any idea what the problem could be?

Wild guess: buffer overrun?

Try surrounding the buffer with "guards".

Code: Select all

int x = 0xDEADBEEF;
char buffer[100];
int y = 0xDEADBEEF;

Then make sure the guard variables around the buffer don't get changed. If they do, the kernel wrote too much and corrupted the stack.

Except that the kernel isn't really doing anything, and the driver is reading the buffer, not writing. Either way, I've changed the design so that there can't be a problem anymore - copying through the kernel is much more robust anyway.