es05.ppt [호환 모드] - koreatechmicrocom.koreatech.ac.kr/course backup/ifc410/lecture...embedded...

Embedded Systems KUT1-1

Embedded Systems

Prof. Myung-Eui Lee (A-405)[email protected]


Linux Structure

l Linux Structure

System Call Interface

Buffer Cache

Memory Manager

Process ManagerFilesystem Manager

Device Manager Network Manager

Ext2fs proc devfs

minix nfs msdos

Console KBD SCSICD-ROM PCI network

Ipv6 ethernet

…..

Memory Management

Process ManagementSchedulerSignaling

Device Interface

proc1 proc2 proc3 proc4 proc5 procn

dev1 dev2 dev3 dev4 devn

char block

User Space

Kernel Space


Linux Structure

l Linux Structure

Computer Hardware

System Shared Libraries (System Call Interface)

Applications: Graphics UI, Compilers, Media player

API

UI

BIOS

Text UI = Shell: sh, csh, ksh, bash, tcsh, zsh

Compiler libraries (libc.a)

Device DrivesKernel

File management

Memory management

Process management


System Call Interface

System CallAPI – System call – OS Relationship

Standard C Lib.C program invoking printf() library call,

which calls write() system callar –t /usr/lib/libc.a | grep printf /usr/src/linux-2.4/arch/i386/kernel/entry.S


System Call

l System calls define the programmer interface to Linux system » Interface between user-level processes and hardware

devicesu CPU, memory, disks etc.

» Make programming easieru Let kernel take care of hardware-specific issues

» Increase system securityu Let kernel check requested service via system call

» Provide portabilityu Maintain interface but change functional implementation

l Roughly five categories of system calls in Linux» Process control» File management» Device management» Information maintenance» Communication

* 288 system callsrefer to slide #6


System Call

l Invoked by executing int or swi instruction» CPU switches to kernel mode & executes a kernel function

l Linux files relating to system call» /usr/src/linux-2.4/arch/i386/kernel/entry.S x86 host #408

/pxa270/kernel/linux-2.6…/arch/arm/kernel/calls.S ARM target #17 u System call and low-level fault handling routinesu ENTRY(sys_call_table)

» /usr/src/linux-2.4/include/asm-i386/unistd.h x86 host /pxa270/kernel/linux-2.6…/include/asm-arm/unistd.h ARM target

u System call numbers and macros

x86 : movl %eax, 2 ; system call numberint $0x80

ARM : swi 2 ; system call number


ARM System Call

l ARM System Call ExampleAn example to write a short file on disk

SWI_Exit EQU 0x01SWI_Write EQU 0x04SWI_Open EQU 0x05SWI_Close EQU 0x06write_only EQU 4 ; mode 4 = open to write

ENTRY ; mark first instruction to execute start ADR r0, filename ; r0 points to string

MOV r1, #write_only ; file attribute for write onlySWI SWI_Open ; open a file for writingMOV r5, r0 ; save file-handle in r5ADR r1, string ; point to a stringMOV r2, #14 ; 14 characters longSWI SWI_Write ; write to fileMOV r0, r5 ; restore file-handleSWI SWI_Close ; close the fileSWI SWI_Exit

filename = "test.txt",0string = "Hello World!",&0a,&0dEND


System Call

l System Call Handling

idt_tabledivide_error()

debug()

nmi()

….

0x0

system_call()

….

kerneluser task

main(){….fork()

}

libc.a

….fork(){….movl %eax, 2int $0x80….

}….

ENTRY(system_call) /* arch/i386/kernel/entry.S */

SAVE_ALL

….call *SYMBOL_NAME(sys_call_table)(,%eax,2)

….ret_from_sys_call (schedule, signal, bh_active,

nested interrupt handling)

0x80

sys_call_table

sys_exit()

sys_fork()

sys_read ()

sys_write ()

….

1

2

3

4

sys_fork()

/* arch/i386/kernel/process.c */

/* kernel/fork.c */


Process

l Program» Structured set of commands stored in an executable file

on a file system» Executed to create a process

l Process» Program running in memory and on the CPU (active

program)» Modern systems allow ‘multiprogramming’ (i.e., several

processes exist concurrently)» Each process requires an allocation of cpu time, in order

to make forward progress» The OS must do ‘scheduling’ of cpu time» Each process also needs the use of other system facilities

(memory, files, devices)» The terms job (batch system) and process is almost used

interchangeably


Process

l A process includes» text section : program » stack» data section» heap

l User process» Process begun by a user that runs on a

terminal (tty)l Daemon process

» System process » Not associated with a terminal

l Process ID (PID) top, ps -el» Unique identifier assigned to every process as

it begins» Processes are identified by their process

identifier, an integer

Process in memory


Process

l Child processes» Refers to a process that was started by another process

(parent process)l Parent processes

» Process that has started other processes (child processes)

l Parent Process ID (PPID) ps -el» The PID of the parent process that created the current

processl Processes communicate via pipes (IPC)

» Queues of bytes between two processes that are accessed by a file descriptor


Processl Process System Call

» Creation : fork system call creates new processu the process that calls fork() is parent, the new process is childu fork() is calling sys_fork() → do_fork() in /kernel/fork.cu “cloning flags” : man clone /usr/src/linux-2.4/include/linux/sched.h #39

» Execution : exec system call is used after a fork to execute the process

» Exit : exit terminates process and free all resourcesu Calling exit() → sys_exit() → do_exit () explicit kernel/exit.c u The child is turned into a zombie process until the parent makes the

call to wait→ When a process finishes execution, it will have an exit status to

report to its parent process. Because of this last little bit of information, the process will remain in the operating system’s process table as a zombie process. indicating that it is not to be scheduled for further execution, but that it cannot be completely removed (and its process ID cannot be reused)

» Wait : A parent may wait for a child process to terminate, and return its termination status

Refer to Slide #26


Process

l Process termination » Voluntary termination

1. Returning to the main() function (implicit)2. Calling exit() (explicit)

» Involuntary termination1. An exception might be raised during its kernel mode execution2. The process might have received the SIGABRT or other termination

signal» Termination process state

1. the parent is alive : zombie process 2. the parent is dead : orphan process

An orphan process is a process that is still executing, they do not become zombie processes; instead, they are adopted(inherited) by init process (PID 1)

l Task» Another name for a process is a task, and Linux kernel

internally refers to processes as tasks» Generally refer to a process from the kernel’s point of view


Task

» As seen by a process running under Linux

u The kernel is a provider of servicesu Individual processes exist

independently alongside each other and cannot affect each other directly

u Each process’s own area of memory is protected against modification by other processes

» The internal viewpoint of a running Linux

u Only one program (OS) is running on the computer, can access all the resource

u The various tasks are carried out by co-routines

u An error in the kernel programming can block the entire system

Process and Tasks


Process Control Block (PCB)

l Information associated with each process l type sturcture task_struct ; line 382 (target:528)

» /usr/src/linux-2.4/include/linux/sched.hProcess stateUnique process identifierMemory-management information File system informationSignal informationProgram counterCPU registersCPU scheduling information (e.g., priority)Accounting informationI/O status informationPointers to other control blocks


memory-map

open files

pid

next_taskprev_taskgid

processor register-values(EIP, ESP, EFLAGS, etc)

signal-handlers

timers

task-state task-priority

task-name

terminal

processexecution aspects

resourceownership aspects

Process Control Block (PCB)

l task_struct


Process Control Block

l task_structstruct task_struct {

volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */unsigned long flags; /* per process flags */mm_segment_t addr_limit; /* thread address space:

0-0xBFFFFFFF for user-thead0-0xFFFFFFFF for kernel-thread */

struct exec_domain *exec_domain;long need_resched;long counter;long priority;/* SMP and runqueue state */

struct task_struct *next_task, *prev_task;struct task_struct *next_run, *prev_run;...

/* task state *//* limits *//* file system info *//* ipc stuff *//* tss for this task */

…/* open file information *//* memory management info *//* signal handlers */

...};

mm_struct

signal_struct

task_struct

pid = 5

mm

slg

files

files_struct


Thread

l Thread of execution = Threadl The object of activity within the processl Each thread includes a unique program counter,

process stack, and set of processor registersl The kernel schedules individual threads, not

processl Linux does not differentiate between threads and

processes : a thread is just a special kind of process

l A process has two distinct aspects » Its ‘execution’ (forward progression of states)» Its ‘ownership’ (share of system’s resources) » The word ‘thread’ refers to the execution aspect of a

process (i.e., the entity which gets ‘scheduled’ by an Operating System for a share of the available cpu time)


Thread

l Multi-threading» It is possible for an operating system to support a

concept of ‘process’ in which more than one execution-thread exists (with process-resources being shared)

l Advantages of ‘threads’» All the ‘threads’ that belong to a process can access the

same memory, the same files, the same terminal, the same timers and the same signal-handlers

» Thus the system ‘overhead’ involved in managing a multithreaded task is more efficient (less time-consuming to set up and keep track of) than if each of those threads had individualized ownerships

one process withone thread

one process withmultiple threads


Thread

l Thread communication» Since the threads in a process share the same memory,

no special mechanism is needed for them to communicate data

process

All these threads can read or write the same memory-locations


User/Kernel Mode Transition

» 1. P1 in User Mode issues a system call

» 2. The process switches to Kernel Mode, and the system call is serviced

» 3. P1 then resumes execution in User Mode until a timer interrupt occurs

» 4. The scheduler is activated in Kernel Mode

» 5. P2 starts its execution in User Mode until a hardware device raises an interrupt

» 6. As a consequence of the interrupt, P2 switches to Kernel Mode and services the interrupt

Transitions between User and Kernel Mode

P1.aRequest system call service

P1.bWait for timerinterrupt

P2.aWait for device H/W interrupt

P2.bDevice H/Winterrupt service

Scheduler

P1.a P1.b P2.a P2.b

System call handler Interrupt handler


Memory Space

l Virtual Memory = User + Kernel

0xFFFFFFFF

text

data

bss

stack

kernel

0x00000000

kernel text

kernel data

kernel stack

kernel bss

User

0xBFFFFFFF

0xC0000000

kernelspace

user space

textdata

stack

textdata

stackmappings

3-GB

1-GB

physical memory virtual memory


Process State

l TASK_RUNNING : 1. running / 2. ready» The process is runnable

u 1. currently running - runningu 2. on a run queue waiting to run - ready

l TASK_INTERRUPTIBLE : waiting/sleeping/blocked» Waiting on a condition: interrupts, or signals » Becomes runnable if it receives a signal

l TASK_UNINTERRUPTIBLE» Waiting process cannot be woken by a signal » Cannot become runnable if it receives a signal» This is used in situations where the process must wait

without interruptionl TASK_STOPPED : temporarily stopped

» Stopped process - e.g., by a debugger» This occurs if the process receives SIGSTOP signal


Process State

l TASK_ZOMBIE : zombie, defunct, immortal process» Process finished, but parent has not released PID » Process has completed execution but still has an entry in the

process table. This entry is still needed to allow the parent process that started the (now zombie) process to read its exit status

» When a process ends, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process's entry in the process table remains. The parent can read the child's exit status by executing the wait system call, at which stage the zombie is removed

» The process has terminated, but its parent has not yet issued a wait system call

» wait provides the process id of a terminated child so that the parent can tell which child terminated


Process State

l 2.4» TASK_RUNNING» TASK_INTERRUPTIBLE» TASK_UNINTERRUPTIBLE» TASK_STOPPED » TASK_ZOMBIE» TASK_DEAD : currently not used

l 2.6» TASK_RUNNING» TASK_INTERRUPTIBLE» TASK_UNINTERRUPTIBLE» TASK_STOPPED» TASK_ZOMBIE» TASK_DEAD : currently not used» TASK_TRACED : being traced by a debugger

/usr/src/linux-2.4/include/linux/sched.h Line # 106

/pxa270/kernel/ linux-2.6.11-h270-tku_v1.1 /include/linux/sched.h


Diagram of Process State


Process

l Context Switch» When CPU switches to another process, the system must

save the state of the old process and load the saved state for the new process

» Context-switch time is overhead; the system does no useful work while switching

» Time dependent on hardware support

l Remote Procedure Call» Remote procedure call (RPC) abstracts procedure calls

between processes on networked systems


Process

l Viewing Processes» ps –f command : user process

u User identifier (UID), PID, PPID, start time, CPU utilization» ps –l command : user process

u More complete informationu Process state can be seen u R = running, S = sleeping, D = uninterruptible sleep,

T = stopped or being traced, Z = zombie» top or ps –efl command : system/user process

u Process priority (PRI) : priority→ Higher value means lower priority→ 0 (high priority) to 139 (low priority)

u Nice value (NI) : time slice→ Indirectly represents priority→ The priority value may be in the range -20 (800ms) to 19(5ms). → Higher value means lower priority

u NICE_TO_PRIO(nice), PRIO_TO_NICE(prio) : kernel/sched.c


InterProcess Communication(IPC)

l Mechanism for processes to communicate and to synchronize their actions

l Message system – processes communicate with each other without resorting to shared variables

l IPC facility provides two operations:» send(message) – message size fixed or variable » receive(message)

l If P and Q wish to communicate, they need to:» Establish a communication link between them» Exchange messages via send/receive

l Implementation of communication link» Physical : shared memory, hardware bus» Logical : logical properties(protocol, layer)


Communications Model

l Direct Communication» Processes must name each other explicitly:» send (P, message) – send a message to process P» receive(Q, message) – receive a message from process Q

l Indirect Communication» Messages are directed and received from mailboxes (also

referred to as ports)» Each mailbox has a unique id» Processes can communicate only if they share a mailbox» Operations

u create a new mailboxu send and receive messages through mailboxu destroy a mailbox

» send(A, message) – send a message to mailbox A» receive(A, message) – receive a message from mailbox A


Signal

l Introduced in UNIX systems to simplify IPCl Used by the kernel to notify processes of

system eventsl A signal is a short message sent to a process,

or group of processes, containing the number identifying the signal

l Linux supports 31 non-RT signals » /include/asm-i386/signal.h

l POSIX standard defines a range of values for RT signals


l A signal is sent due to occurrence of corresponding event (kernel/signal.c – line 1110)» send_sig_info(int sig, struct siginfo *info, struct task_struct *t);

» sig is signal number» info is either:

u 0, if user mode process is signal senderu 1, if kernel is signal sender

# Signal Name Default Action Comment1 SIGHUP Abort Hangup terminal or process2 SIGINT Abort Keyboard interrupt (usually Ctrl-C)

…9 SIGKILL Abort Forced process termination

10 SIGUSR1 Abort Process specific11 SIGSEGV Dump Invalid memory reference

…

Signal


l Sending a signal» Kernel sends (delivers) a signal to a destination process

to update some state in the context of the destination process

l Kernel sends a signal for one of the following reasons:» Generated internally:

u Kernel has detected a system event such as divide-by-zero (SIGFPE) or the termination of a child process (SIGCHLD)

» Generated externally:u Another process has invoked the kill system call to explicitly request

the kernel to send a signal to the destination process

Signal


l Receiving a signal» A destination process receives a signal when it is forced

by the kernel to react in some way to the delivery of the signal

l Three possible ways to react:» Ignore the signal (do nothing)» Terminate the process» Catch the signal by executing a user-level function call(a

signal handler)u Similar to a hardware exception handler being called in response to

an asynchronous interrupt

Signal


Scheduler

l Scheduling» Non-preemptive scheduling: the process keeps the CPU

until the process terminates or it switches to waitingstate (simple to implement)

» Preemptive scheduling: the process can be interruptedand must release the CPU

l Scheduling Policies : /include/linux/sched.h Line # 136» SCHED_NORMAL : non-RT / classic Unix

u Interactive : make the system appear fast to useru RT have higher priorities than any non-RT tasks

» SCHED_FIFO : soft-RTu If no other higher-priority RT process is runnable, the process will

continue to use the CPU as long as it wishes» SCHED_RR : soft-RT

u Assign CPU time to all SCHED_RR processes that have the samepriority (fixed time slice)

u Interrupted when its time slice has expired* Scheduler schedule() function : /kernel/sched.c - line 986


Scheduler

l Long-term scheduler (or job scheduler) » Selects which processes should be brought into the

ready queue» Invoked very infrequently (seconds, minutes) Þ (may

be slow)l Short-term scheduler (or CPU scheduler)

» Selects which process should be executed next and allocates CPU

» Invoked very frequently (milliseconds) Þ (must be fast)

l Processes can be described as either:» I/O-bound process – spends more time doing I/O than

computations, many short CPU bursts» CPU-bound process – spends more time doing

computations, few very long CPU bursts

Linux implicitly favors I/O-bound processes over CPU-bound ones


Module

l Linux is a monolithic kernel» Trivial modifications require kernel to be recompiled» Kernel is increasing in size by adding new features» Many modules occupy permanent space in memory

though they are used rarelyl Module: steps toward micro-kernelized Linux

» Small and compact kernel» Clean kernel» Rapid kernel» Components-based Linux

l Easier way to extend Linux kernel functionsl Modules allow to plug a new functionality into the

kernel at runtime» A module is loaded only when it is needed» It is unloaded when it is not needed anymore


Module

l LKM (Linux Kernel Module) = Kernel Module = Module

l Linux Kernel = Base Kernel (Kernel Image) + LKMl Kernel does not need to be rebuilt so often

» Reduce the likeliness of errorsl Bugs in code do not affect the kernel boot

» Easier debugging: you know where to look» Faster debugging: no need to reboot

l Modules can be compiled and dynamically linked into kernel address space» Useful for device drivers that need not always be resident

until needed.u Keeps core kernel “footprint” small


Module versus Application

l Modules» 1. runs in kernel space

(no main function)» 2. just registers itself in

order to serve future requests, and its initialization function terminates immediately(event-driven program)

» 3. no libraries to link to (linked only to the kernel): the only functions it can call are the ones exported by the kernel

u printk() : kernel function

l Applications» 1. runs in user space

(main function)» 2. performs a single task

from beginning to end(not all applications are event-

driven) » 3. can call functions it

doesn’t define: the linking stage resolves external references using the appropriate library of functions (libc)

u printf()


Module

l Every module consist of two basic functions (minimum)int init_module(void) /*used for all initialization*/ { ... } void cleanup_module(void) /*used for exit */ { ... }

l Loading a module - by issuing the following command: » insmod module.o

l Removing a module - by issuing the following command: » rmmod module


Module

» Basic two Interfacesu module_init()u module_exit()

» Function units which can be implemented as modulesu File system : register_filesystem(), unregister_filesystem(),

read_super function (mount), put_super function (unmount)u Block device drivers : register_blkdev(), unregister_blkdev(), open

function, release function u Character device drivers : register_chrdev(), unregister_chrdev(),

open function, release functionu Network device drivers : register_netdev(), unregister_netdev(), open

function, close function

kernel

module

init_module()

module_init()

cleanup_module()

module_exit()

register

system call

unregister

system call

insmod

rmmod


Module

l Instruction» insmod : /proc/modules

u Insert an module into the kernel» rmmod

u Remove an module from the kernel» depmod : /lib/modules/2.4.20-8/modules.dep

u Determine interdependencies between modules» ksyms : /proc/ksyms

u Display symbols that are exported by the kernel » lsmod = /proc/modules

u List currently loaded modules» modinfo

u Display module information (.modinfo section in module object file)» modprobe : /etc/modules.conf (alias & options)

u Insert module and resolve module dependency (as described by modules.dep). For example, if you must load A before loading B, modprobe will automatically load A when you tell it to load B


Module

l modinfo hello.o» MODULE_AUTHOR(“MELEE”);» MODULE_DESCRIPTION(“Hello Module”);» MODULE_LICENCE(“GPL”);

l /proc/ksyms : Kernel Symbol Table» lists all the symbols the kernel exports» /usr/src/linux/System.map (core symbols)» /proc/ksyms (all symbols)

l /proc/modules » holds information about the loaded modules» column : module name / size / use count / dependency

l /etc/modules.conf » modprobe command» A module name : eth0, usb-controller » A more generic identifier : e100, ehci-hcd


Module

l kernel 2.4 : host/* HELLO MODULE example -Tested on Linux Kernel 2.4 */

#include #include #include

MODULE_LICENSE("GPL");MODULE_AUTHOR(“MELEE”);MODULE_DESCRIPTION(“HELLO MODULE”);

int init_module(void){

printk("HELLO MODULE is loaded. \n");

return 0;}

void cleanup_module(void){

printk("HELLO MODULE is unloaded. \n");}

## Makefile for Linux Kernel Module for 2.4

CC = gcc

KERNEL_PATH = /usr/src/linux-2.4.20-8CFLAGS = -DMODULE -D__KERNEL__ -I$(KERNEL_PATH)/include

MOD_OBJ = hello

all: $(MOD_OBJ).o

$(MOD_OBJ): $(MOD_OBJ).c$(CC) $(CFLAGS) -c $(MOD_OBJ).c

clean:rm -f *.o

-D__KERNEL__ = #define __KERNEL__-DMODULE = #define MODULE


Module

l kernel 2.6 : target/* HELLO MODULE example - Tested on Linux Kernel 2.6.x */

#include #include #include

MODULE_LICENSE("GPL");

int hello_init(void){

printk(" HELLO MODULE is loaded. \n");

return 0;}

void hello_exit(void){

printk(" HELLO MODULE is unloaded. \n");}

module_init(hello_init);module_exit(hello_exit);

## Makefile for Linux Kernel Module for 2.6

obj-m := hello.o

CC := /opt/iwmmxt-1.0.0/bin/arm-linux-gcc

KDIR := /pxa270/kernel/linux-2.6.11-h270-tku_v1.1

PWD := $(shell pwd)

default:$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

clean:rm -rf *.ko rm -rf *.mod.*rm -rf .*.cmdrm -rf .tmp*rm -rf *.o


Module

l Make module : sample modules (microcom homepage)l Load the module

» insmod hello.o or hello.ko» dmesg : at host (2.4) or /var/log/messages

l Check that the module is loaded» lsmod = cat /proc/modules

l Remove the module» rmmod hello» dmesg : at host (2.4)

es05.ppt [호환 모드] - koreatechmicrocom.koreatech.ac.kr/course backup/ifc410/lecture...embedded...

Documents