Transcript osd05

CS 6560 Operating System
Design
Lecture 5:
System Calls
Interrupts
System Calls
• LKD: Chapter 4: System Calls
References
• Our textbook: Robert Love, Linux Kernel
Development, 2nd edition, Novell Press, 2005.
• Understanding the LINUX Kernel, 3rd. edition,
O’Reilly, 2005. (covers 2.6)
• Class notes at Georga Tech:
– http://www-static.cc.gatech.edu/classes/AY2001/cs3210_spring/
• Intel Documentation:
– http://developer.intel.com/design/index.htm
Why System Calls?
• Need a model and a mechanism for users to access
system resources, which is
–
–
–
–
User portable: abstracts kernel to users
Device portable: abstracts kernel to devices
Safe: protects users and devices
Efficient: simple and fast
Standardization
• POSIX: IEEE 1003
– Describes Kernel Application Interface (API)
(more at the level of a C library)
How?
• User program calls a C function which
jumps into the kernel
• Architecture dependent, for x86, two ways:
– Software interrupt
– Sysenter instruction: see Intel Docs
Design Principles
• System calls should
– Have a single purpose
– Implement method, not policy
Steps for System Call
• 1) Push registers on stack
• 2) call library function
• 3) place function # in register (register eax on x86) (or
stack)
• 4) execute INT instruction (INT 80h on x86 machines) or
special sys call instruction
• 5) dispatch to sys call interrupt handler, change to
privileged mode
• 6) runs sys_xx function in the kernel
• 7) return to library function in user mode
• 8) return back to program
• 9) clean up the stack
Function Call Numbers
• See man 2 intro - This is the man chapter on
system calls (may be out of date)
• Locate unistd.h files in various places
– In the system for app development
• /usr/include/asm/
• /usr/include/kernel/
– In the kernel development files
• include/asm-
• Locate entry point - depends upon arch. For
example, for i386:
./arch/i386/kernel/syscall_table.S:
.long sys_fork
Entry Points
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ENTRY(sys_call_table)
.long sys_restart_syscall
/* 0 - old "setup()" system call, used for restarting */
.long sys_exit
.long sys_fork
.long sys_read
.long sys_write
.long sys_open
/* 5 */
.long sys_close
.long sys_waitpid
.long sys_creat
.long sys_link
.long sys_unlink
/* 10 */
.long sys_execve
.long sys_chdir
.long sys_time
Numbers correspond
•
•
#ifndef _ASM_I386_UNISTD_H_
#define _ASM_I386_UNISTD_H_
•
•
•
/*
* This file contains the system call numbers.
*/
•
•
•
•
•
•
•
•
•
•
•
#define __NR_restart_syscall 0
#define __NR_exit
1
#define __NR_fork
2
#define __NR_read
3
#define __NR_write
4
#define __NR_open
5
#define __NR_close
6
#define __NR_waitpid
7
#define __NR_creat
8
#define __NR_link
9
#define __NR_unlink
10
include/asm-i386/unistd.h
same as /usr/include/
•
•
#ifndef _ASM_I386_UNISTD_H_
#define _ASM_I386_UNISTD_H_
•
•
•
/*
* This file contains the system call numbers.
*/
•
•
•
•
•
•
•
•
•
•
•
•
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
__NR_restart_syscall
__NR_exit
__NR_fork
__NR_read
__NR_write
__NR_open
__NR_close
__NR_waitpid
__NR_creat
__NR_link
__NR_unlink
__NR_execve
0
1
2
3
4
5
6
7
8
9
10
11
Details
• Read in the book:
– How it works
– How to make one
• Look at Georgia Tech class notes
– Diagrams
– More details
– Strace function
• HW assignment next week to make and install a
system call
Final point
• Don’t just add more system calls - keep the
kernel interface simple
Interrupts
• LKD Ch6
Why Interupts?
• Allow CPU to exchange data with slow
devices
• Handle exceptions - error conditions
• Provide protected access to resources such
as the kernel
How do Interrupts Work?
• Use Interrupt handlers: Interrupt service
routines (ISR)
–
–
–
–
Just C functions that can be called at any time
Must return quickly
Run in special context
Must be registered (Use: request_itq)
Example ISR
• See the text for an example
Interrupt Context
• Context (while in kernel):
– Process Context
• Executing a system call on behalf of a process
• current points to task_struct of current process
– Interrupt Context
• Reponding to an interrupt
• current points to task_struct of whatever process
was interrupted
Top and Bottom Halves
• Conflicting needs:
– Return quickly
– Get lots of work done
• Solution: Break up the interrupt processing into
two parts
– Top half: returns quickly, after setting up work to be
done
– Bottom half: scheduled by the kernel to get work done
at a later time (see next chapter)
/proc entry
• Look at /proc/interrupts
Details
• Read the book for more details
– Disabling and enabling interrupts
– Knowing status of an interrupt
• More needed: must know a lot more before
writing any code, see
/usr/src/linux/Documentation
• Next time: look at example and study deferred
work: top and bottom halves