2012-04-06 17:49:35 +02:00
|
|
|
#
|
|
|
|
# For a description of the syntax of this configuration file,
|
2015-06-28 16:08:57 +02:00
|
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
2012-04-06 17:49:35 +02:00
|
|
|
#
|
2013-03-10 20:31:10 +01:00
|
|
|
|
2014-08-28 20:09:49 +02:00
|
|
|
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
|
2014-08-29 22:47:22 +02:00
|
|
|
lies outside of the kernel such as when the BUILD_PROTECTED or
|
|
|
|
BUILD_KERNEL builds are selected.
|
2014-08-28 20:09:49 +02:00
|
|
|
|
|
|
|
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.
|
2013-03-10 20:31:10 +01:00
|
|
|
|
2014-08-28 20:09:49 +02:00
|
|
|
if LIB_SYSCALL
|
2013-03-17 17:13:28 +01:00
|
|
|
|
2013-03-10 20:31:10 +01:00
|
|
|
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.
|
|
|
|
|
2013-03-17 17:13:28 +01:00
|
|
|
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.
|
|
|
|
|
2014-08-28 20:09:49 +02:00
|
|
|
endif # LIB_SYSCALL
|