OSDev.org

I've been studying about operating systems is already some time. One issue that is calling me to attention is the communication between processes and with the kernel.

A kernel that is using paging, usually, it separates an area of virtual memory (ex.: 1GB). So be 1GB for kernel and 3GB for the user programs. What I do not understand is how to communicate a process with the kernel.

Suppose, if a program opens a file for reading or writing, he will pass a pointer over 1GB, which is not visible to the kernel. My question is: how to make kernel communicate with the process?

1) Create a buffer in the kernel space (below to 1GB), and make the user program to copy or read the data in the buffer;
2) Load the kernel with the same Page Directory of the process;

Another issue is the inter-process communication. Where a pipe is created? In the kernel space?

And when a parent process creates a child process and want to pass parameters to the child process, where the kernel stores the strings? In the kernel space too?

Thanks already.

arabasso wrote:Suppose, if a program opens a file for reading or writing, he will pass a pointer over 1GB, which is not visible to the kernel.

Not true. The whole idea about 1G/3G division is defining ownership of virtual ranges, not availability. All kernel things will take place in the kernel area, while everything the application sees must be in the application area.

Both can try to access the entire address space, however user applications do not have the privilege to access kernel pages and will fault, while the kernel can access the less privileged areas. The kernel can thus alter both its own area, and the user's area.

The kernel is able to read and write to any part of the user address space. All you need to do is have the user process make a request for data, along with a userspace address to store it at, and have the kernel copy the data to that address. It's really as simple as a memcpy() (once you have the data from the disk/input device of course ). IPC just requires copying data into the kernel, switching to another address space, then copying it out again. I'm assuming a monolithic design here - microkernels have to do IPC for all data requests.

Okay, i know that the kernel has full access to memory. But i'm thinking about the problem of pagination. The kernel is not access an address without mapping pages.

In my model kernel (microkernel), i reserve 1GB for the kernel heap, and above that for the user programs. As i need more memory, i map more pages and increase the kernel heap.

Then when i create a new process, i clone the kernel page directory and create a new PD for the process. The case is: if I did not map the memory (over 1GB) for the kernel, it gives page fault!

Would have a problem set the CR3 register with the page directory of the process that i must read or write data?

NickJohnson wrote:All you need to do is have the user process make a request for data, along with a userspace address to store it at, and have the kernel copy the data to that address. It's really as simple as a memcpy()

There is a bit more to it than that.

The user process could pass the kernel a pointer to an unmapped area of memory, and cause an exception in kernel space. The kernel has to be prepared for this.

Even worse, the user process could pass in an address within the kernel's protected region. The user process can't access this memory directly, but if it can trick the kernel into reading or writing there, it could cause all kinds of havoc.

But if you take account of these things (x86 segment registers can help), then yeah, it's basically a memcpy().

You can avoid bounds checking, for example if the kernel specifically allocates a 4kb page when the program starts up, and says to the application "this is your IPC buffer". Then when you send a message to another process, either: you can memcpy it into the kernel (without worrying the program gave a bad pointer) or do it without any memory copying, for example swap that page with the IPC page in another process.

It all depends on the primitives for communicating you want, you can send short messages, pages at a time, have pages mapped to two or more address spaces/processes at once, have pipes streams, or a much slower inbox system for large messages.