System Calls
202310081637
Status: #idea
Tags: OS
System Calls
- The only legal entry point into the kernel code
- Provides an abstract interface for hardware to user-space programs
- Kernel can keep track of an applications activities, by tracking its syscalls
Dynamic linking - Library is loaded only if it is used in the program
Linux and Solaris are hybrid systems.
The kernel has both monolithic and modular parts
Windows is mostly monolithic. Some subsystems use microkernels
Application Binary Interface (ABI) is the architechture equivalent of an API
System Design Goals
- User goals
- Convenient to use
- Easy to learn
- Reliable
- Fast and responsive
- System goals
- Easy to design, implement and maintain
- Flexible
- Reliable, error-free and efficient
Mechanism - How to do things
Policy - Decided what to be done
Separation between mechanism and policy is important to allow for flexible design
EAX/RAX stores the syscall number before you reach the common entrypoint for all syscalls
The registers are filled with appropriate values before running INT 0x80
This interrupt is used to transfer control from user to kernel
Having more than 5 parameters passed to a system call leads to memory protection checks, increasing overhead
This is is because there are 5 usable registers
How a syscall works
- Check if the syscall number in EAX is valid
- User data is pushed to the stack
- Jump to the location of the syscall number starts, and execute it
- Pop the stack
- Return control to the user
How to pass data from user to kernel
- If
, we can use EBX,ECX,EDX,ESIandEDI - Pass by reference
- Put start address of data in user-space memory
- User program can push into stack. System call will pop from the stack
- This design is avoided as the code which pushes and pops from the stack is different
System calls in Linux are not vectored.
The entrypoint to kernel code is same for all syscalls.
A system call leads to loss of locality of reference, causing cahce misses and pipeline flushes.
A syncronous read operation is blocking.
An async read is non-blocking.
Transitions b/w user and kernel space are more expensive than a function call.
This is because all context needs to be saved.
Designing a System Call
- Serve a single purpose
- Ensure that it can be implemented across all architectures. Should be portable
- Verify validity of all arguments
- Ensure that all pointers passed are legal
- Ensure that pointer is in user space
- Ensure that it points to a region in the process's address space
- If writing, ensure that the region is writable
Ensure that the full memory region passed is suitable, and not just the first and last locations.
Difference b/w syscall and function call
- A system call is typically accessed by means of a function call
- A system call involves mode switching
- syscall has more overhead than a function call
- Almost all syscalls return something (at least status codes)
2 ways to save context:
- Selective backup (of registers)
- Save all - Done in Intel - Few registers
Some RISC architectures have 100's of registers. Here, selective backup is preferred
Smallest time slice is
Extremely small time slices lead to a lot of overhead due to frequent context switches
If you want to write a highly efficient program, you can directly raise the interrupt with the corresponding syscall number
Disadvantages of System Calls
- Needs a syscall number, which needs to be officially assigned to your syscall, during the kernel development series
- Once mainlined, the interface can not change without breaking user-space programs
- Each architecture needs to separately register the system call and support it
- For simple exchange of information, a syscall is overkill