[Linux Kernel Development]Presentation for Chapter 4: System Calls

[Status: Draft]
[Version: v0.5]
[Last modified: 2004-02-10 14:15]

Title: Linux Kernel Development
Author: Robert Love
Pages: xxvi + 332
ISBN: 0672325128
Format: Paperback
Publisher: SAMS, Developer Library Series
Publish Date: 8 Sept 2003

http://tech9.net/rml/kernel_book/

Chapter 4 System Calls

APIs, POSIX, and the C Library

API:
- Application Programming Interface
- Applications are programmed against an API, not directly to syscalls
- The same API can exist on multiple systems and provide the same interface to applications while...
- The implementation of the API itself can differ from system to system.
POSIX:
- Portable Operating System Interface for UNIX
- is comprised of a series of standards from the IEEE
- aims to provide a portable operating system standard roughly based on Unix
- Linux is POSIX compliant
- POSIX is an excellent example of the relationship between APIs and system calls.
C library:
- implements the main API on Unix systems, including the standard C library and the system call interface.

Syscalls

System calls:
- System calls are often called syscalls in Linux
- have a defined behavior
- are accessed via function call
- can define one ore more arguments
- might result in one or more side effects
- provide a return value that signifies success or error

asmlinkage:
- a modifier on the function declaration
- tells the compiler to look only on the CPU stack for this function's arguments, instead of registers
- a required modifier for all system calls
- detailed explanation: http://www.kernelnewbies.org/faq/#asmlinkage

System Call Numbers

Each system call
- is assigned a unique syscall number
- cannot change or else!
- is defined in entry.S
- You cannot recycle a system call number even if that system call is removed

System Call Performance

Fast! Because......
- Linux has incredibly fast context switch times
- the simplicity of the system call handler and the individual system calls themselves

System Call Handler

- Sits between user-space applications and kernel-space
- Handle the software interrupt from user-space
- Signal the kernel, have the system switch to kernel mode, where the system call can be executed in kernel-space

Denoting the Correct System Call

To pass the system call number into the kernel on x86:
1. Store the number in the eax register
2. Issue the software interrupt, so that the system call handler reads the value from eax

Parameter Passing

- Same way as passing the system call number:
store in registers
- On x86, use ebx, ecx, edx, esi, and edi for first five arguments
- Got six arguments or even more? Use a single register to hold a pointer to user-space
- Return value is sent back to user-space via eax register on x86

System Call Implementation

Dos and Don'ts of system calls:
Do:
- Implement for exactly on purpose
- Clean and simple interface
- Smallest number of arguments possible
- Portability and robustness
Don't:
- Multiplex syscalls, such as ioctl()
- Assume its use today will be the same as its use tomorrow
- Make assumptions about an architecture's wordsize or endianness

Verifying the Parameters

Every parameter must be checked to ensure it is not just valid and legal, but correct.
Ensure these before following a pointer into user-space:
- The pointer points to a region of memory in user-space
- The pointer points to a region of memory in the process's address space
- If reading, the memory is marked readable. If writing, the memory is marked writable

copy_to_user() and copy_from_user() functions:
- reads from the 2nd parameter into the 1st parameter the amount of bytes specified in the 3rd parameter
- return the number of bytes they failed to copy on error

System Call Context

During the execution of a system call, the kernel:
- is in process context
- is capable of sleeping
- is fully preemptible

Final Steps in Binding a System Call

- Add an entry to the end of the system call table, entry.S
- Define the syscall number in include/asm/unistd.h for each architecture supported
- Compile the syscall into the kernel image, not as a module

Accessing the System Call from User-Space

Linux provides a set of macros for wrapping access to system calls: _syscalln(), where n is between zero and six.

Why Not to Implement a System Call

The pros, cons, and alternatives of implementing a new interface as a syscall:
The pros:
- System calls are simple to implement and easy to use
- System call performance on Linux in blindingly fast
The cons:
- Need to be officially assigned a syscall number during a developmental kernel series
- After the system call is in a stable series kernel, it is written in stone
- Each architecture needs to separately register the system call and support it
- For simple exchanges of information, a system call is overkill
The alternatives:
- Implement a device node and read() and write() to it. Use ioctl() to manipulate specific settings or retrieve specific information
- Certain interfaces, such as semaphores, can be represented as file descripters and manipulated as such
- The current trend is to implement a simple RAM-based filesystem where files represent the specific interfaces. Applications perform normal file I/O on the files to access the interface