aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHimbeer <himbeer@disroot.org>2024-08-01 19:17:35 +0200
committerHimbeer <himbeer@disroot.org>2024-08-01 19:17:35 +0200
commita48cc8fb04a796df301f94f27b4373a59b24457c (patch)
tree4bd97a1ded2bc8fa80e1b3336413f84934124482
parentec36e106116415188392d78b1a0ce8955a499867 (diff)
Add dedicated SRVRE message passing documentation page
-rw-r--r--static/md/srvre/kernel/wiki/msgpass.md40
1 files changed, 40 insertions, 0 deletions
diff --git a/static/md/srvre/kernel/wiki/msgpass.md b/static/md/srvre/kernel/wiki/msgpass.md
new file mode 100644
index 0000000..e57b0e2
--- /dev/null
+++ b/static/md/srvre/kernel/wiki/msgpass.md
@@ -0,0 +1,40 @@
+---
+title: "Message passing - SRVRE Kernel Wiki"
+date: "Thu Aug 1 2024"
+---
+
+Message passing is the most basic mechanism for inter-process communication,
+mainly between drivers and their dependants.
+
+Channels
+========
+
+All messages are transferred over channels which logically separate their data
+flows and destinations. Channels deliver messages to all subscribed processes
+(even if another process has already handled a message other processes will
+still receive it), but there is no guarantee that a process actually listens
+for and handles them and no retransmissions even if there are no channel
+members, so senders expecting a response should implement a timeout. This
+approach was chosen over an explicit error because the caller will have to wait
+before retrying anyway. Messages are only truncated on the receiving end, and
+only if the buffer the message is read into is insufficiently sized. Senders do
+not have to join the channels they transmit on. The ordering of transmitted
+messages is preserved, though they may be interspersed with messages from other
+senders or other threads of the sender process.
+
+Messages can be passed on a channel using the
+[pass](/md/srvre/kernel/wiki/syscalls.md#join-100010) [system
+call](/md/srvre/kernel/wiki/syscalls.md), optionally specifying a single
+receiver process by ID if broadcasting is not the desired behavior. The sender
+may choose to expose its process ID to enable the receiver to send a unicast
+response.
+
+Messages can be received asynchronously using the
+[receive](/md/srvre/kernel/wiki/syscalls.md#receive-100011) [system
+call](/md/srvre/kernel/wiki/syscalls.md), optionally retrieving the ID of the
+sender process or zero if the sender is anonymous. The sender process ID is trustworthy and can be used for security purposes.
+
+Channels can be joined using the
+[join](/md/srvre/kernel/wiki/syscalls.md#join-100008) [system
+call](/md/srvre/kernel/wiki/syscalls.md) and left using
+[leave](/md/srvre/kernel/wiki/syscalls.md#leave-100009).