diff options
| author | Kimplul <kimi.h.kuparinen@gmail.com> | 2022-09-23 00:43:40 +0300 |
|---|---|---|
| committer | Kimplul <kimi.h.kuparinen@gmail.com> | 2022-09-23 00:43:40 +0300 |
| commit | 12bfd21818b7a90887dd4c6a92817b791fdb7600 (patch) | |
| tree | cf77d225d0c0e5304d301dc5de4cfe6445171d26 /common/uapi | |
| parent | ae3905ebeb415e12667777463e36df6e00ca992c (diff) | |
| download | kmi-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.c | 1 | ||||
| -rw-r--r-- | common/uapi/ipc.c | 15 |
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 }; } |
