#
# 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.