aboutsummaryrefslogtreecommitdiff
path: root/common/uapi
diff options
context:
space:
mode:
authorKimplul <kimi.h.kuparinen@gmail.com>2022-09-23 00:43:40 +0300
committerKimplul <kimi.h.kuparinen@gmail.com>2022-09-23 00:43:40 +0300
commit12bfd21818b7a90887dd4c6a92817b791fdb7600 (patch)
treecf77d225d0c0e5304d301dc5de4cfe6445171d26 /common/uapi
parentae3905ebeb415e12667777463e36df6e00ca992c (diff)
downloadkmi-12bfd21818b7a90887dd4c6a92817b791fdb7600.tar.gz
kmi-12bfd21818b7a90887dd4c6a92817b791fdb7600.zip
remove user data from sys_ipc_notify
+ Multiple notify signals at the same time, or queued ones waiting for ipc_req/fwd to finish would require a notify stack of some kind, which is maybe too complex for my liking. Not impossible by any means, but I want to keep things simple. Let's say a client wants the server to do some async operation. First, the client calls ipc_req to inform the server that it would like the operation to be done. The server sets this task in some work queue or whatever, and returns to the client as quickly as possible. Later on, when the task is finished, the server does a ipc_req to the client, with data about what was just finished. The client is responsible for noting this data down somewhere, either reacting to the operation directly in the callback, or calling ipc_notify to the thread that requested the operation. Other possible notifications at the same time should be handled at the same time, whichever way the client wants to handle them. Note that ipc_notify triggers only when the thread it targets is in its base state, i.e. not doing an ipc_req. This makes things a bit easier.
Diffstat (limited to 'common/uapi')
-rw-r--r--common/uapi/dispatch.c1
-rw-r--r--common/uapi/ipc.c15
2 files changed, 10 insertions, 6 deletions
diff --git a/common/uapi/dispatch.c b/common/uapi/dispatch.c
index 6d70cd4..f2a12d6 100644
--- a/common/uapi/dispatch.c
+++ b/common/uapi/dispatch.c
@@ -36,6 +36,7 @@ static const sys_t syscall_table[] = {
[SYS_IPC_REQ] = sys_ipc_req,
[SYS_IPC_FWD] = sys_ipc_fwd,
[SYS_IPC_RESP] = sys_ipc_resp,
+ [SYS_IPC_NOTIFY] = sys_ipc_notify,
/* proc */
[SYS_CREATE] = sys_create,
diff --git a/common/uapi/ipc.c b/common/uapi/ipc.c
index fa0376a..141b494 100644
--- a/common/uapi/ipc.c
+++ b/common/uapi/ipc.c
@@ -84,13 +84,16 @@ SYSCALL_DEFINE4(ipc_resp)(sys_arg_t d0, sys_arg_t d1, sys_arg_t d2,
*
* @param tid Thread ID to notify.
* @param swap Whether to swap immediately if possible.
- * @param a0 Argument 0.
- * @param a1 Argument 1.
* @return \ref OK and 0.
*/
-SYSCALL_DEFINE4(ipc_notify)(sys_arg_t tid, sys_arg_t swap,
- sys_arg_t a0, sys_arg_t a1){
+SYSCALL_DEFINE2(ipc_notify)(sys_arg_t tid, sys_arg_t swap){
/** \todo masquerade as kernel call, set from to 0 and set us as
- * notify type, with arguments a0 and a1 as user-configurable data. */
- return (struct sys_ret){ OK, 0, 0 /* type */, 0 /* from */, a0, a1 };
+ * notify type, no arguments as that would require too much state
+ * handling for my liking. Instead, a server and a client have to agree
+ * on some rpc API, and ipc_notify is just used to asynchronously inform
+ * the client that it should check the status of its async operations.
+ * Arguably slower than directly telling the client which operation was
+ * finished, but this would require the kernel to keep track of a notify
+ * stack. While not impossible, probably too complex. */
+ return (struct sys_ret){ OK, 0, 0 /* type */, 0 /* from */, 0, 0 };
}