#
# 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"
	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_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