OSDev.org

OSwhatever wrote:Synchronous messages works fine here as long as both sender and receiver knows how much data will be coming before hand. The receiver buffer can reside anywhere in user space and do not require any particular alignment, also synchronous messages do not need any kind of buffering in the kernel. This method is however slow compared to giving physical pages directly. For real speed you should look at L4 kernel map and grant way to do it, basically giving a page from one process to another.

OSwhatever wrote:For memory mapped files: use map/grant way.
For reading file to anywhere in the user memory: use synchronous messages of arbitrary length.

In the file system hierarchy, you use map/grant almost exclusively except in the last step to the user process that reads the file.

giszo wrote: At the receiver side I should know somehow the size of the arbitrary data before trying to receive the message to give a proper sized buffer to the kernel. Unfortunately without asking for the size of the message I could not really know it however this would require one more system call beside the receiver one. One more option would be to define the absolute maximum size of these messages (let's say 1Mb) and the sender should not send more than this at a time. This way the receiver can have a buffer that is suitable for receiving any kind of message. Any other way to solve this issue?

struct OS_signal
{
   unsigned int size;
   unsigned int signal_number;
   char payload[1];
}

struct OS_signal *
signal_alloc(unsigned int size, unsigned int signal_number)
{
    struct OS_signal *siggie;

    siggie = malloc(sizeof(struct OS_signal) + size - 1);
    if(!siggie) 
    {
        log_error();
        return NULL;
    }

    siggie->signal_number = signal_number;
    siggie->size = size;
    return siggie;
}

giszo wrote: Let's say at first I would only implement synchronous IPC calls for communication between different processes in the system. Using this synchronous IPC for the whole communication between app<->VFS and VFS<->FS would lead into a problem in case of there is only one thread handling the requests inside the VFS because while serving the request of app1 is waiting for the underlying FS driver to complete the operation would prevent a concurrent request from app2 to get executed. How could I solve this? Use multiple threads to process requests in a server? ... but how many?

giszo wrote:Two questions here...

At the receiver side I should know somehow the size of the arbitrary data before trying to receive the message to give a proper sized buffer to the kernel. Unfortunately without asking for the size of the message I could not really know it however this would require one more system call beside the receiver one. One more option would be to define the absolute maximum size of these messages (let's say 1Mb) and the sender should not send more than this at a time. This way the receiver can have a buffer that is suitable for receiving any kind of message. Any other way to solve this issue?

Let's say at first I would only implement synchronous IPC calls for communication between different processes in the system. Using this synchronous IPC for the whole communication between app<->VFS and VFS<->FS would lead into a problem in case of there is only one thread handling the requests inside the VFS because while serving the request of app1 is waiting for the underlying FS driver to complete the operation would prevent a concurrent request from app2 to get executed. How could I solve this? Use multiple threads to process requests in a server? ... but how many?

Thank you for this tip, I will look into the details of it.

Am I right if I think that this could be used with asyncronous communication in VFS, FS drivers, etc. and it would also solve the second issue I mentioned before?

OSwhatever wrote:Usually, each file read will give you any length equal or less the read length you passed as parameter and in that way you can prevent any overflow. My kernel will pass the size of message that arrives and that way the user program will know it too.

giszo wrote:That is fine, my problem is the other way around when the user process want to write to a file. It passes a buffer with its size to the appropriate IPC method to send the request. The receiver (VFS) should provide a buffer large enough to store the sent data, however it does not really have an idea about the size of the sent message.

giszo wrote:I would have one more topic that is not strongly connected to the original subject of the topic however we already touched it before, so I'm asking here. What would be a good way for implementing request handling in system services like the VFS server?

If I want to use the same synchronous IPC method I am going to use between apps and the VFS it would require one thread per request in the VFS server. OSwhatever mentioned before he avoided this problem by starting a new thread for each request. Is this really a good way?

The other way I could think of is to use asynchronous IPC with some kind of method like NickJohnson pointed out to pass memory pages between user processes. This way I could avoid storing message data inside the kernel when messages are queued at an IPC port because the data is already stored by the user process. However I am still worried because this method still requires a lot of support in the servers to be able to keep track of pending requests.

OSwhatever wrote:When I mentioned that I started a thread for each file system operation, that's a truth with modification. If there are 200 file system requests, 200 threads are of course not created. A maximum set of threads (depends how many CPUs you have and what is most optimum for that particular operation) are created and the remaining pending file system requests are queued. This is usually called a thread pool.

giszo wrote:I was worried about creating a thread per request because it would mean a lot of allocation inside the kernel per request. Using a thread pool for this purpose makes sense however it is still a good question how you decide the optimal size of this pool.

Do you use synchronous IPC everywhere in your project?

giszo wrote:I am in the process of designing an implementing the IPC mechanism of my hobby microkernel project and I need some help mostly regarding design considerations.

I faced the first problem when I tried to implement the communication between an usual userspace process and the VFS server because I need to pass a lot of data between them when the process wants to read or write some kind of file, etc. At first I implemented my IPC messages with fixed size (6 * 8 bytes) to avoid queueing big message data inside the kernel. I thought that this problem can be solved with the help of creating a shared memory region per (to stick with the previous example) file descriptor. This region could be used to put the data there that should be written and vice versa. I started to worry about my design when I thought about what happens when multiple threads are trying to access the same file at the same time, the simple shared memory region will not be enough.

• Small IPCs might go through a memory mapped ringbuffer shared between the ends of the communications channel (With the kernel providing the ability to "prod" or "wake up" the other end)
• Large IPCs happen by some form of per-IPC page mapping

• The receiver must explicitly allocate the buffers it is to receive into. If the sender attempts to "string copy" more data, or map more pages than is allowed, the IPC is denied
• The sender and receiver always get the option of not waiting for an IPC

Owen wrote:Don't try to invent "One grand unified solution" if it doesn't make sense. As I'd do it:

• Small IPCs might go through a memory mapped ringbuffer shared between the ends of the communications channel (With the kernel providing the ability to "prod" or "wake up" the other end)