pussuw commented on a change in pull request #5782:
URL: https://github.com/apache/incubator-nuttx/pull/5782#discussion_r837115104
##########
File path: arch/risc-v/include/syscall.h
##########
@@ -391,6 +396,64 @@ static inline uintptr_t sys_call6(unsigned int nbr,
uintptr_t parm1,
return r0;
}
+#ifdef CONFIG_ARCH_USE_S_MODE
+
+/* In S-mode the kernel cannot ecall to itself, because ecall will raise
+ * privileges to M-mode, which is not what we want. Instead, use the syscall
+ * trampoline to do the same.
+ */
+
+static inline uintptr_t ksys_call3(unsigned int nbr, uintptr_t parm1,
Review comment:
> > The reason I chose the name ksys_call() and made the separate
functions is analogous to how for example the memory allocators are implemented
now. There are separate malloc/kmalloc functions for example. Both are needed.
This is the case with the syscall functions also.
>
> But kmm_malloc will map to malloc in flat build, which make kmm_malloc
work in all possible mode(flat, protected and kernel). sys_callx should hand in
the same way, which mean that either user or kernel could call these function
if the want to invoke the kernel function, its the responsibility of sys_callx
to map the implementation to the right action base on the environment.
Yes, I agree it should be a mapping, the details of the implementation could
be hidden in e.g. syscall.h. The problem with the function name sys_callx is
that it is directly referenced by the libc functions. So in this case what the
function should do depends where the reference comes from, which at least to me
makes using the same function name very difficult.
Unless there is a separate build process for libc and kernel ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
