sycall/README.txt
=================
This directory supports a syscall layer from communication between a
monolithic, kernel-mode NuttX kernel and a separately built, user-mode
application set.
With most MCUs, NuttX is built as a flat, single executable image
containing the NuttX RTOS along with all application code. The RTOS code
and the application run in the same address space and at the same kernel-
mode privileges. In order to exploit security features of certain
processors, an alternative build model is also supported: NuttX can
be built separately as a monolithic, kernel-mode module and the applications
can be add as a separately built, user-mode module.
The syscall layer provided in this directory serves as the communication
layer from the user-mode application into the kernel-mode RTOS. The
switch from user-mode to kernel-mode is accomplished using software
interrupts (SWIs). SWIs are implemented differently and named differently
by different manufacters but all work essentially the same: A special
instruction is executed in user-mode that causes a software generated
interrupt. The software generated interrrupt is caught within the kernel
and handle in kernel-mode.
Header Files
============
include/syscall.h
This header file supports general access to SWI facilities. It is simply
a wrapper file that includes include/sys/syscall.h and
include/arch/syscall.h.
include/sys/syscall.h
The SWIs received by the kernel are distinguish by a code that identifies
how to process the SWI. This header file defines all such codes understood
by the NuttX kernel.
include/arch/syscall.h (or arch/<cpu>/include/syscall.h)
This header file is provided by the platform-specific logic and declares
(or defines) the mechanism for providing software interrupts on this
platform. The following functions must be declared (or defined) in this
header file:
- SWI with SYS_ call number and one parameter
uintptr_t sys_call0(unsigned int nbr);
- SWI with SYS_ call number and one parameter
uintptr_t sys_call1(unsigned int nbr, uintptr_t parm1);
- SWI with SYS_ call number and two parameters
uintptr_t sys_call2(unsigned int nbr, uintptr_t parm1, uintptr_t parm2);
- SWI with SYS_ call number and three parameters
uintptr_t sys_call3(unsigned int nbr, uintptr_t parm1,
uintptr_t parm2, uintptr_t parm3);
- SWI with SYS_ call number and four parameters
uintptr_t sys_call4(unsigned int nbr, uintptr_t parm1, uintptr_t parm2,
uintptr_t parm3, uintptr_t parm4);
- SWI with SYS_ call number and five parameters
uintptr_t sys_call5(unsigned int nbr, uintptr_t parm1, uintptr_t parm2,
uintptr_t parm3, uintptr_t parm4, uintptr_t parm5);
- SWI with SYS_ call number and six parameters
uintptr_t sys_call6(unsigned int nbr, uintptr_t parm1, uintptr_t parm2,
uintptr_t parm3, uintptr_t parm4, uintptr_t parm5,
uintptr_t parm6);
Syscall Database
================
Sycall information is maintained in a database. That "database" is
implemented as a simple comma-separated-value file, syscall.csv. Most
spreadsheets programs will accept this format and can be used to maintain
the syscall database.
The format of the CVS file for each line is:
Field 1: Function name
Field 2: The header file that contains the function prototype
Field 3: The type of function return value.
Field 4 - N+4: The type of each of the N formal parameters of the function
Auto-Generated Files
====================
Stubs and proxies for the sycalls are automatically generated from this CSV
database. Here the following definition is used:
STUB - A tiny bit of code that executes with within the NuttX kernel that
is used to map a software interrupt received by the kernel to a
kernel function call.
Proxy - Another tiny bit of code that executes in the user space. A proxy
has exactly the same function prototype as does the "real" function
for which it proxies. However, it only serves to map the function
call into a syscall, marshalling all of the parameters as necessary.
a521443817