Embedded Real-time Systems
The Linux kernel
The Operating System Kernel
• Resident in memory, privileged mode• System calls offer general purpose services• Controls and mediates access to hardware• Implements and supports fundamental abstractions:
– Process, file (file system, devices, interprocess communication)
• Schedules / allocates system resources:– CPU, memory, disk, devices, etc.
• Enforces security and protection• Event driven:
– Responds to user requests for service (system calls)– Attends interrupts and exceptions– Context switch at quantum time expiration
What is required?
• Applications need an execution environment:– Portability, standard interfaces– File and device controlled access– Preemptive multitasking– Virtual memory (protected memory, paging)– Shared libraries– Shared copy-on-write executables– TCP/IP networking– SMP support
• Hardware developers need to integrate new devices– Standard framework to write device drivers– Layered architecture dependent and independent code– Extensibility, dynamic kernel modules
Linux Execution Environment
Memory
b
STANDARD CLIBRARY
MATHLIBRARYAPPLICATION (mpg123)
MemoryManagement
FilesystemsNetworking
ArchitectureDependent
Code
MemoryManager
File SystemDevices
CharacterDevices
NetworkSubsystem
OPERATING SYSTEM
ProcessManagement
DeviceControl
Network InterfacesCPU
Disk
• Program
• Libraries
• Kernel subsystems
Linux Execution Environment
• Execution paths
Memory
b
STANDARD CLIBRARY
MATHLIBRARYAPPLICATION (mpg123)
MemoryManagement
FilesystemsNetworking
ArchitectureDependent
Code
MemoryManager
File SystemDevices
CharacterDevices
NetworkSubsystem
OPERATING SYSTEM
ProcessManagement
DeviceControl
Network InterfacesCPU
Disk
malloc
_sbrk
fprintf
vfprintf
writeread
_isnan
sin
pow
Decoder
I/O
HTTP
Network
Initialization
socket
tan
log
wait
rand
qsortscanf
valloc
Linux source code
Linux source code layout
• Linux/arch– Architecture dependent code.– Highly-optimized common utility routines such as memcpy
• Linux/drivers– Largest amount of code – Device, bus, platform and general directories– Character and block devices , network, video– Buses – pci, agp, usb, pcmcia, scsi, etc
• Linux/fs– Virtual file system (VFS) framework.– Actual file systems:
• Disk format: ext2, ext3, fat, RAID, journaling, etc• But also in-memory file systems: RAM, Flash, ROM
Linux source code layout
• Linux/include– Architecture-dependent include subdirectories.– Need to be included to compile your driver code:
• gcc … -I/<kernel-source-tree>/include …
– Kernel-only portions are guarded by #ifdefs #ifdef __KERNEL__
/* kernel stuff */
#endif
– Specific directories: asm, math-emu, net, pcmcia, scsi, video.
Process and System Calls
• Process: program in execution. Unique “pid”. Hierarchy.• User address space vs. kernel address space• Application requests OS services through TRAP mechanism
– x86: syscall number in eax register, exception (int $0x80)– result = read (file descriptor, user buffer, amount in bytes)– Read returns real amount of bytes transferred or error code (<0)
• Kernel has access to kernel address space (code, data, and device ports and memory), and to user address space, but only to the process that is currently running
• “Current” process descriptor. “currentpid” points to current pid• Two stacks per process: user stack and kernel stack• Special instructions to copy parameters / results between user and
kernel space
Scheduling processes
• Process scheduling is done at the following events:– 1. the running process switches to the waiting state,– 2. the running process switches to the ready state,– 3. a waiting process switches to the ready state (the
woke up process may have higher priority than the previously running process), or
– 4. a process terminates.
• If scheduling occurs only at 1 and 4, we have non-preemptive scheduli
Preemptive vs non-preemptive scheduling
• With preemptive scheduling, another process can be scheduled at any time.
• A process which is updating shared data must ensure that no other process also starts using the data (by using a lock for instance).
• The first UNIX kernels were non-preemptive which simplified their design, but user processes where scheduled preemptively.
• With multiprocessors, UNIX kernels were rewritten with preemptive kernel Process scheduling
Scheduling criteria 1
• CPU utilisation: how busy the CPU is with user processes,
• Throughput: number of processes completed per time unit,
• Turnaround time: how long time it takes for one process to execute,
• Waiting time: how long time a process sits in the ready queue, and
• Response time: how long time it takes before a user gets some response (must be very small — otherwise too annoying).
• These goals are contradictory, unfortunately
Scheduling criteria 2
• A short response time requires frequent re-scheduling.
• Context-switching time can be several percent and compute-intensive jobs are best run to completion with as little scheduling as possible.
• For instance, running two long compute-intensive simulations after each other is better on UNIX than running the concurrently (despite losing positive effects of multiprogramming).
• In addition to context-switching time, frequent rescheduling increases the number of cache misses.
Top Related