AOS Lab 5: System calls

599 views
468 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
599
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

AOS Lab 5: System calls

  1. 1. Lab 5: System calls Advanced Operating Systems Zubair Nabi zubair.nabi@itu.edu.pk February 27, 2013
  2. 2. Normal execution of a processor While running a user process: 1 Read an instruction 2 Advance the program counter 3 Execute the instruction 4 Jump to 1
  3. 3. Normal execution of a processor While running a user process: 1 Read an instruction 2 Advance the program counter 3 Execute the instruction 4 Jump to 1
  4. 4. Normal execution of a processor While running a user process: 1 Read an instruction 2 Advance the program counter 3 Execute the instruction 4 Jump to 1
  5. 5. Normal execution of a processor While running a user process: 1 Read an instruction 2 Advance the program counter 3 Execute the instruction 4 Jump to 1
  6. 6. Normal execution of a processor While running a user process: 1 Read an instruction 2 Advance the program counter 3 Execute the instruction 4 Jump to 1
  7. 7. Extraordinary events Events that break normal processor flow, to return control to the kernel: 1 A device signals that it needs attention (e.g. Timer): Interrupt 2 A user program does something illegal (e.g. divide by zero): Exception 3 A user program asks the kernel for a service: System call
  8. 8. Extraordinary events Events that break normal processor flow, to return control to the kernel: 1 A device signals that it needs attention (e.g. Timer): Interrupt 2 A user program does something illegal (e.g. divide by zero): Exception 3 A user program asks the kernel for a service: System call
  9. 9. Extraordinary events Events that break normal processor flow, to return control to the kernel: 1 A device signals that it needs attention (e.g. Timer): Interrupt 2 A user program does something illegal (e.g. divide by zero): Exception 3 A user program asks the kernel for a service: System call
  10. 10. Extraordinary events Events that break normal processor flow, to return control to the kernel: 1 A device signals that it needs attention (e.g. Timer): Interrupt 2 A user program does something illegal (e.g. divide by zero): Exception 3 A user program asks the kernel for a service: System call
  11. 11. Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  12. 12. Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  13. 13. Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  14. 14. Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  15. 15. Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  16. 16. Handling extraordinary events The operating system must: 1 Save the processor’s registers for future resumption 2 Set up system for execution in the kernel 3 Choose a place for the kernel to start execution 4 Retrieve information about the event and call corresponding interrupt handler 5 All the while, maintain isolation between user processes and the kernel
  17. 17. Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  18. 18. Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  19. 19. Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  20. 20. Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  21. 21. Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  22. 22. Handling extraordinary events (2) • Need hardware support • On the x86, system calls generate an interrupt via the int instruction • The same mechanism for handling interrupts is used for handling system calls and exceptions • Traps are caused by the current running process • Interrupts are caused by devices • Can happen concurrently
  23. 23. x86 protection • 4 protection levels: 0 to 3 • Privilege decreases in ascending order • Most operating systems only use 2 levels: 0 (kernel mode) and 3 (user mode) • Interrupt handlers are defined in an interrupt descriptor table (idt) with a total of 256 entries • int n generates a system call, where n is used to index the idt • It is the job of the operating system to implement a handler for each entry in the idt
  24. 24. x86 protection • 4 protection levels: 0 to 3 • Privilege decreases in ascending order • Most operating systems only use 2 levels: 0 (kernel mode) and 3 (user mode) • Interrupt handlers are defined in an interrupt descriptor table (idt) with a total of 256 entries • int n generates a system call, where n is used to index the idt • It is the job of the operating system to implement a handler for each entry in the idt
  25. 25. x86 protection • 4 protection levels: 0 to 3 • Privilege decreases in ascending order • Most operating systems only use 2 levels: 0 (kernel mode) and 3 (user mode) • Interrupt handlers are defined in an interrupt descriptor table (idt) with a total of 256 entries • int n generates a system call, where n is used to index the idt • It is the job of the operating system to implement a handler for each entry in the idt
  26. 26. x86 protection • 4 protection levels: 0 to 3 • Privilege decreases in ascending order • Most operating systems only use 2 levels: 0 (kernel mode) and 3 (user mode) • Interrupt handlers are defined in an interrupt descriptor table (idt) with a total of 256 entries • int n generates a system call, where n is used to index the idt • It is the job of the operating system to implement a handler for each entry in the idt
  27. 27. x86 protection • 4 protection levels: 0 to 3 • Privilege decreases in ascending order • Most operating systems only use 2 levels: 0 (kernel mode) and 3 (user mode) • Interrupt handlers are defined in an interrupt descriptor table (idt) with a total of 256 entries • int n generates a system call, where n is used to index the idt • It is the job of the operating system to implement a handler for each entry in the idt
  28. 28. x86 protection • 4 protection levels: 0 to 3 • Privilege decreases in ascending order • Most operating systems only use 2 levels: 0 (kernel mode) and 3 (user mode) • Interrupt handlers are defined in an interrupt descriptor table (idt) with a total of 256 entries • int n generates a system call, where n is used to index the idt • It is the job of the operating system to implement a handler for each entry in the idt
  29. 29. x86 protection • 4 protection levels: 0 to 3 • Privilege decreases in ascending order • Most operating systems only use 2 levels: 0 (kernel mode) and 3 (user mode) • Interrupt handlers are defined in an interrupt descriptor table (idt) with a total of 256 entries • int n generates a system call, where n is used to index the idt • It is the job of the operating system to implement a handler for each entry in the idt
  30. 30. int • Fetches the nth descriptor from idt • Ensures that the privilege level in the descriptor is 3 • As the interrupt is due to a user process, saves the process state (change in privilege level) • Sets the instructor pointer to the required starting address in the descriptor table and starts execution • After execution, the OS calls iret to resume previous execution state
  31. 31. int • Fetches the nth descriptor from idt • Ensures that the privilege level in the descriptor is 3 • As the interrupt is due to a user process, saves the process state (change in privilege level) • Sets the instructor pointer to the required starting address in the descriptor table and starts execution • After execution, the OS calls iret to resume previous execution state
  32. 32. int • Fetches the nth descriptor from idt • Ensures that the privilege level in the descriptor is 3 • As the interrupt is due to a user process, saves the process state (change in privilege level) • Sets the instructor pointer to the required starting address in the descriptor table and starts execution • After execution, the OS calls iret to resume previous execution state
  33. 33. int • Fetches the nth descriptor from idt • Ensures that the privilege level in the descriptor is 3 • As the interrupt is due to a user process, saves the process state (change in privilege level) • Sets the instructor pointer to the required starting address in the descriptor table and starts execution • After execution, the OS calls iret to resume previous execution state
  34. 34. int • Fetches the nth descriptor from idt • Ensures that the privilege level in the descriptor is 3 • As the interrupt is due to a user process, saves the process state (change in privilege level) • Sets the instructor pointer to the required starting address in the descriptor table and starts execution • After execution, the OS calls iret to resume previous execution state
  35. 35. The first system call • Recall that initcode.S started off by invoking an exec system call to load the init process (/init) • Flow: 1 Push the arguments and binary for exec on the process’s stack 2 Put the system call number (SYS_exec) in %eax (obviously this number should already be present in the system call table, *syscalls[]) 3 Execute int T_SYSCALL
  36. 36. The first system call • Recall that initcode.S started off by invoking an exec system call to load the init process (/init) • Flow: 1 Push the arguments and binary for exec on the process’s stack 2 Put the system call number (SYS_exec) in %eax (obviously this number should already be present in the system call table, *syscalls[]) 3 Execute int T_SYSCALL
  37. 37. The first system call • Recall that initcode.S started off by invoking an exec system call to load the init process (/init) • Flow: 1 Push the arguments and binary for exec on the process’s stack 2 Put the system call number (SYS_exec) in %eax (obviously this number should already be present in the system call table, *syscalls[]) 3 Execute int T_SYSCALL
  38. 38. The first system call • Recall that initcode.S started off by invoking an exec system call to load the init process (/init) • Flow: 1 Push the arguments and binary for exec on the process’s stack 2 Put the system call number (SYS_exec) in %eax (obviously this number should already be present in the system call table, *syscalls[]) 3 Execute int T_SYSCALL
  39. 39. The first system call • Recall that initcode.S started off by invoking an exec system call to load the init process (/init) • Flow: 1 Push the arguments and binary for exec on the process’s stack 2 Put the system call number (SYS_exec) in %eax (obviously this number should already be present in the system call table, *syscalls[]) 3 Execute int T_SYSCALL
  40. 40. x86 traps • 256 different interrupts • 0-31 software • 32-63 hardware • 64 system calls (T_SYSCALL)
  41. 41. x86 traps • 256 different interrupts • 0-31 software • 32-63 hardware • 64 system calls (T_SYSCALL)
  42. 42. x86 traps • 256 different interrupts • 0-31 software • 32-63 hardware • 64 system calls (T_SYSCALL)
  43. 43. x86 traps • 256 different interrupts • 0-31 software • 32-63 hardware • 64 system calls (T_SYSCALL)
  44. 44. Setting up idt • tvinit, called from main, sets up the entries in idt • The address of the handler for each interrupt in idt is present in vectors[], i.e. Interrupt i is handled by vectors[i] • T_SYSCALL is handled specially: it is distinguished as a trap allowing multiple system calls to execute simultaneously
  45. 45. Setting up idt • tvinit, called from main, sets up the entries in idt • The address of the handler for each interrupt in idt is present in vectors[], i.e. Interrupt i is handled by vectors[i] • T_SYSCALL is handled specially: it is distinguished as a trap allowing multiple system calls to execute simultaneously
  46. 46. Setting up idt • tvinit, called from main, sets up the entries in idt • The address of the handler for each interrupt in idt is present in vectors[], i.e. Interrupt i is handled by vectors[i] • T_SYSCALL is handled specially: it is distinguished as a trap allowing multiple system calls to execute simultaneously
  47. 47. tvinit 1 2 3 4 5 6 7 8 9 10 11 12 13 14 void tvinit (void) { int i; for(i = 0; i < 256; i++) SETGATE (idt[i], 0, SEG_KCODE <<3, vectors [i], 0); SETGATE (idt[ T_SYSCALL ], 1, SEG_KCODE <<3, vectors [ T_SYSCALL ], DPL_USER ); /∗ SETGATE (gate , istrap , sel , off , d) ∗ ∗ ∗ ∗ ∗ gate: idt entry istrap : 1 trap , 0 interrupt sel: code segment off: offset within code segment d: privilege level ∗/ initlock (& tickslock , "time"); }
  48. 48. Addresses of interrupt handlers • xv6 uses a custom Perl script vectors.pl to generate vectors.S which holds entry points of interrupt handlers in vectors[] • Each entry point: Pushes an error code Pushes the interrupt number 3 Jumps to alltraps 1 2
  49. 49. Addresses of interrupt handlers • xv6 uses a custom Perl script vectors.pl to generate vectors.S which holds entry points of interrupt handlers in vectors[] • Each entry point: Pushes an error code Pushes the interrupt number 3 Jumps to alltraps 1 2
  50. 50. Addresses of interrupt handlers • xv6 uses a custom Perl script vectors.pl to generate vectors.S which holds entry points of interrupt handlers in vectors[] • Each entry point: Pushes an error code Pushes the interrupt number 3 Jumps to alltraps 1 2
  51. 51. Addresses of interrupt handlers • xv6 uses a custom Perl script vectors.pl to generate vectors.S which holds entry points of interrupt handlers in vectors[] • Each entry point: Pushes an error code Pushes the interrupt number 3 Jumps to alltraps 1 2
  52. 52. alltraps 1 Pushes all processor registers into a struct trapframe • Once the call completes, the kernel can restore state from this structure 2 Sets up the processor to run kernel C code (load SEG_KCPU, per-CPU data segment) 3 Calls the C trap handler trap 4 Once trap returns, alltraps restores struct trapframe and then calls iret to return control back to user space
  53. 53. alltraps 1 Pushes all processor registers into a struct trapframe • Once the call completes, the kernel can restore state from this structure 2 Sets up the processor to run kernel C code (load SEG_KCPU, per-CPU data segment) 3 Calls the C trap handler trap 4 Once trap returns, alltraps restores struct trapframe and then calls iret to return control back to user space
  54. 54. alltraps 1 Pushes all processor registers into a struct trapframe • Once the call completes, the kernel can restore state from this structure 2 Sets up the processor to run kernel C code (load SEG_KCPU, per-CPU data segment) 3 Calls the C trap handler trap 4 Once trap returns, alltraps restores struct trapframe and then calls iret to return control back to user space
  55. 55. alltraps 1 Pushes all processor registers into a struct trapframe • Once the call completes, the kernel can restore state from this structure 2 Sets up the processor to run kernel C code (load SEG_KCPU, per-CPU data segment) 3 Calls the C trap handler trap 4 Once trap returns, alltraps restores struct trapframe and then calls iret to return control back to user space
  56. 56. alltraps 1 Pushes all processor registers into a struct trapframe • Once the call completes, the kernel can restore state from this structure 2 Sets up the processor to run kernel C code (load SEG_KCPU, per-CPU data segment) 3 Calls the C trap handler trap 4 Once trap returns, alltraps restores struct trapframe and then calls iret to return control back to user space
  57. 57. trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  58. 58. trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  59. 59. trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  60. 60. trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  61. 61. trap • Gets passed struct trapframe *tf • Checks tf->trapno to decide if it was called for a system call (T_SYSCALL) or a hardware interrupt or an exception • In case of: 1 System call, it invokes syscall 2 3 Hardware interrupt, it calls the hardware interrupt controller Exception, it prints the details and kills the user process
  62. 62. syscall • Loads the system call number through proc->tf->eax • Calls the corresponding system call from the syscalls table • Puts its return value in proc->tf->eax (available on return to user space) • Conventionally negative numbers indicate errors while positive ones indicate success • System call arguments are retrieved using either argint, argptr, or argstr
  63. 63. syscall • Loads the system call number through proc->tf->eax • Calls the corresponding system call from the syscalls table • Puts its return value in proc->tf->eax (available on return to user space) • Conventionally negative numbers indicate errors while positive ones indicate success • System call arguments are retrieved using either argint, argptr, or argstr
  64. 64. syscall • Loads the system call number through proc->tf->eax • Calls the corresponding system call from the syscalls table • Puts its return value in proc->tf->eax (available on return to user space) • Conventionally negative numbers indicate errors while positive ones indicate success • System call arguments are retrieved using either argint, argptr, or argstr
  65. 65. syscall • Loads the system call number through proc->tf->eax • Calls the corresponding system call from the syscalls table • Puts its return value in proc->tf->eax (available on return to user space) • Conventionally negative numbers indicate errors while positive ones indicate success • System call arguments are retrieved using either argint, argptr, or argstr
  66. 66. syscall • Loads the system call number through proc->tf->eax • Calls the corresponding system call from the syscalls table • Puts its return value in proc->tf->eax (available on return to user space) • Conventionally negative numbers indicate errors while positive ones indicate success • System call arguments are retrieved using either argint, argptr, or argstr
  67. 67. Reading(s) • Chapter 3, “Traps, interrupts, and drivers”, till section “Code: System calls" from “xv6: a simple, Unix-like teaching operating system”

×