This page is available in: en

Anatomy of a T-Engine System Call

Written by: Mohit Sindhwani

This article looks at the structure of a system call in the T-Engine environment. In this article, source file references are to the that is available from the T-Engine Forum website.

System Calls

In many processors, a system call is a special trap that transfers control from the user space to the supervisor space (in the case of an OS, a system call takes the processor into the kernel space). System calls are frequently used in the design of operating systems to allow an application to request services from the OS.

System Calls in the T-Engine

In the T-Engine (as with other operating systems), applications use system calls to request the system for special services. The bulk of the services in a T-Engine environment are provided by the T-Kernel and T-Monitor. However, there may also be other services that are provided as part of the port for a specific processor. A list of trap numbers (for services) in a T-Engine system are listed in the file: \include\tk\sysdepend\[TE_TYPE]_[CPU]\sysdef_depend.h (replace [TE_TYPE] with something like “std” or “mic” and [CPU] with the CPU name – for example, mic_m32104 for a micro T-Engine based on M32104).

Near the end of the file, there is a list of “trap numbers”. In the case of my port to the TriCore TC1775, the list of numbers is something like this (this is just a partial list):


/*
 * Trap number for T-Kernel
 */

#define TRAP_SVC     2  /* T-Kernel system call/extended SVC */

/*
 * Trap number for T-Monitor
 */

#define TRAP_MONITOR 0  /* T-Monitor service call */

System Call Function Codes

From the list above, it is clear that this port is implemented such that system call 0 is for the T-Monitor and system call 2 is for the T-Kernel. Both the T-Kernel and the T-Monitor offer a number of different services that can be accessed from an application using system calls. The specific service to be executed is identified using system call function codes. Every service has a function code associated with it. This code must be passed to the system call service provider so that it can decide which service is needed.

  • In addition to the extended service, there are 10 system calls for the T-Monitor. The list and associated numbers are in: \lib\libtm\src\tmon.h
  • For the T-Kernel, the list of 109 system calls and the associated function codes are in a number of files, such as: \include\sys\svc\tkfncd.h

Parameters to the System Call

Like ordinary C functions, a system call may receive one or more parameters from the application and may return a value. In the case of the T-Kernel system calls, the number of parameters is encoded into the function code itself. In the case of the T-Monitor system calls, there are fewer calls and the function codes do not include any other information (in fact, function codes for the T-Monitor system calls simply run from 0 to 9). The number and type of parameters for the system calls can be found from the specifications for the T-Monitor and the T-Kernel.

Structure of a System Call

Based on the above information, a T-Engine system call comprises the following parameters:

  1. System call type – whether the system call is for the T-Kernel, T-Monitor, etc. (from the list above, we know that system call 0 is for the T-Monitor, system call 2 is for the T-Kernel, etc.)
  2. System call function code – If the service provider provides a number of services (like the T-Kernel and T-Monitor do), the system call needs to include a system call service number. For example, the system call number for the tk_cre_tsk will be different from tk_del_tsk.
  3. Arguments – similar to any C function, the system call may expect arguments and may return values.

This information is used to create the system call libraries that are usually built in with the application. The system call library for the T-Kernel is in the directory \lib\libsvc and for the T-Monitor, the directory is \lib\libtm – the source code for the system call library can be found in the “src” sub-directories of the above. If you examine the source code of any of the system calls, you will see that it loads the function code of the service, the type of system call and then asserts a trap to switch to the system space. This information is used by the system to find the appropriate handler for the required service.

System Call Control Flow

The system call control flow is shown in the Figure below. The application makes a request for a service by calling a function in the system call service libraries (libsvc for T-Kernel and libtm for T-Monitor – these libraries are part of the specific T-Kernel port). The system call functions load the correct parameters and assert a system call. In response to the system call, the T-Monitor finds the correct trap service provider based on the type of system call, and passes control to the correct provider. The service provider then examines the system call function code and calls the correct function to provide the required service.