85 lines
3.5 KiB
Plaintext
85 lines
3.5 KiB
Plaintext
#
|
|
# For a description of the syntax of this configuration file,
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
|
#
|
|
|
|
menuconfig LIB_SYSCALL
|
|
bool "System call support"
|
|
depends on ARCH_HAVE_SYSCALL && !BUILD_FLAT
|
|
default n
|
|
---help---
|
|
Build in support for "system calls". System calls are used to
|
|
implement a call gate mechanism that can be be used to call from
|
|
user code into the kernel. This is only useful for user code that
|
|
lies outside of the kernel such as when the BUILD_PROTECTED or
|
|
BUILD_KERNEL builds are selected.
|
|
|
|
This permits calls from user-mode code into kernel mode; the call
|
|
gate will change the mode of operation from user to supervisor mode,
|
|
then call into the OS code on behalf of the user-mode application.
|
|
|
|
If if there are no privilege issues preventing the call, system
|
|
calls may also be of value because it can eliminate the need for
|
|
symbol tables when linking external modules to the NuttX base code.
|
|
The selection will build libsyscall. External modules can then link
|
|
with libsyscall when they are built and they can call into the OS
|
|
with no knowledge of the actual address in the OS. In this case,
|
|
they call into a proxy that is link with the external code; that
|
|
proxy then marshals the call parameter and invokes the system call
|
|
to accomplish the interface.
|
|
|
|
if LIB_SYSCALL
|
|
|
|
config SYS_NNEST
|
|
int "Number of nested system calls"
|
|
default 2
|
|
---help---
|
|
This is architecture dependent. Most architectures allocate
|
|
resources to manage a fixed, maximum number of nested system calls.
|
|
A nested system call occurs in the following scenario: (1) A non-
|
|
privileged user thread executes a system call, (2) part of the
|
|
system call processing cause a call back into the user space code,
|
|
and (3) the user space code performs another system call.
|
|
|
|
I don't believe that any nested system calls will occur in the
|
|
current design so the default maximum nesting level of 2 should be
|
|
more than sufficient.
|
|
|
|
config LIB_SYSCALL_EXTENSION
|
|
bool "Custom system call support"
|
|
default n
|
|
---help---
|
|
This allows users to extend syscalls in flat, protected, or kernel
|
|
build modes without modifying the original library syscalls or
|
|
the reserved architecture-specific syscalls.
|
|
It comes helpful when you have some custom libraries
|
|
that require syscalls to trap into the kernel for privileged handling.
|
|
Another senario is that ou need to perform simple benchmarking
|
|
for context switching to inject test logic to verify proper user/kernel
|
|
mode switching.
|
|
With the custom syscall extension mechanism, you can meet these
|
|
specialized requirements without altering the built-in or common syscalls.
|
|
To use this feature, follow these steps:
|
|
1. Create a custom syscall lookup header:
|
|
Write your own syscall_ext_lookup.h file and place it in your
|
|
module's directory. This file maps syscall numbers to their corresponding
|
|
functions.
|
|
2. Define a syscall CSV file:
|
|
Define one/more syscall CSV files, pls see syscals.csv for example
|
|
3. Configure the build system:
|
|
Update your CMakeLists.txt or Makefile to invoke NuttX's mksyscall tool,
|
|
which generates the necessary stubs and proxies for your syscalls.
|
|
For Cmake, we have helper functions to achieve such, pls refer to
|
|
nuttx_syscall_utils.cmake for details.
|
|
|
|
endif # LIB_SYSCALL
|
|
|
|
config LIB_SYSCALL_WRAPPER
|
|
bool "Wrap system call functions"
|
|
default n
|
|
depends on ARCH_HAVE_SYSCALL_HOOKS
|
|
---help---
|
|
Enable this option to wrap system call functions with some
|
|
functions defined. Can use it to protect kernel. rise
|
|
privilege to access kernel data.
|