Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AOS Lab 5: System calls

840 views

Published on

Published in: Technology
  • Be the first to comment

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”

×