Inter-process communication support

[48cf]

This pull request aims to bring an easy way for processes to communicate with each other using dedicated system calls. There is still a lot of work to do, but it's something we can work upon.

The current system works in following way, there are 2 system calls available:

• sys_ipc_send(target_pid, *buffer, flags);
• sys_ipc_recv(*buffer, *sender, *length, flags);

The sys_ipc_send system call should always succeed, there aren't any planned error paths (for now at least). It will return the message ID assigned to the sent message.

The sys_ipc_recv system call will return the received message ID, the sender's PID will be written to the *sender argument and the message payload length will be written to the *length argument. Possible flags include NO_WAIT which makes the system call return with an error code ENOMSG if there aren't any messages in the message queue instead of waiting, and TRUNCATE which will truncate the payload if it's too big to fit in the buffer. By default the system call will return E2BIG and put the message back into the queue if it won't fit in provided buffer.

[48cf]

I think this is an alright approach to the problem, before I turn it into a regular PR I'd still like implement a userland crate to easily built applications that need IPC. I was thinking of using postcard as message format, it's a binary format, it's built using serde and supports no_std :^)

[Andy-Python-Programmer]

I also believe there should be a way to retrieve the rest of the data in the message if the provided buffer is too small to fit the data and we are allowed to truncate it (in this implementation it just gets nuked :rage2: rn). So for example (pseudocode):

ipc_send(MEME_PID, "python is based", IpcFlags::Truncated)

buffer = [0; 7] # strlen("python is based") == 15
response = ipc_get(buffer, buffer.len())

Now we should have recieved the following "python ". The issue is that there should be a way to retrieve the rest of the data aswell. We could possibly store the current read offset but thats probably not the best way this could be done.

[48cf]

Currently my branch doesn't fully work, for some reason a weird crash happens in init where it fails to initialize the standard heap allocator, so that's a thing I need to figure out why it happens. In near future I will add a way for messages to be deserialized into types that implement serde::Deserialize and also support for sending messages :^) One more idea would be to allow the user to pass some kind of a bogus value like -1 as the target PID and have it routed to the init process for ease of use since on Aero the init process isn't PID 0.

[pitust]

i might try implementing my own version of this tbh.

[Andy-Python-Programmer]

Hm sure though I would say to do it in this branch since then we could get something that is solid, fast and we could merge to master