blob: f1138611ac66b7fda37e1e58a3b94a818aab6241 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
#
# For a description of the syntax of this configuration file,
# see misc/tools/kconfig-language.txt.
#
menuconfig LIB_SYSCALL
bool "System call support"
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
likes outside of the kernel such as when the NUTTX_KERNEL build is
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_RESERVED
int "Number of reserved system calls"
default 0
---help---
Kernel system calls may share the same software trapping mechanism
as other functions used by architecture port. Those software traps
must be reserved for use exclusively by the architecture. These
value specifies the number of reserved software traps used by the
architecture; number of the kernel system calls will begin with this
number.
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.
In the current design, this can happen only under one condition:
When the kernel calls back into user space in order to allocate user
space memory. So it is expected that the maximum nesting level will
be only 2.
endif # LIB_SYSCALL
|
