1 / 102

TCP/IP Model, Kernel, Processes

TCP/IP Model, Kernel, Processes. Network API Kernel Functionalities Concept of process. OSI & Internet protocol suite. 2. Where we work?. Sockets API. Open/X Transport Interface. 3. Two reasons for this design. Communication is separated from application layer

butch
Télécharger la présentation

TCP/IP Model, Kernel, Processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TCP/IP Model, Kernel, Processes Network API Kernel Functionalities Concept of process

  2. OSI & Internet protocol suite 2

  3. Where we work? Sockets API Open/X Transport Interface 3

  4. Two reasons for this design • Communication is separated from application layer • Upper three layers form a user process while the lower four layers are provided as part of operating system or kernel.

  5. About kernel

  6. Kernel • the part of the operating system that is mandatory and common to all other software • simply the name given to the lowest level of abstraction that is implemented in software

  7. Functionalities of Kernel • Process Management • Memory Management • Device Management • System Calls

  8. Memory Management • The kernel has full access to the system's memory and must allow processes to safely access this memory as they require it. • Virtual addressing allows the kernel to make a given physical address appear to be another address, the virtual address. • Virtual address spaces may be different for different processes;

  9. Memory Management

  10. System calls • System calls are functions (enhanced instructions) implemented in OS that can be used by user processes. • Handling system calls is like handling interrupts (sometimes call software interrupts). • Instead of a hardware event, the program issues an “interrupt” instruction. • All processors support such an instruction. The semantics of such instructions on different processors are similar (but have some slight differences). • On x86, the instruction is int/iret. • On MIPS, the instruction is syscall. • On some other older machines, the instruction is called trap.

  11. System calls Void open (char *file_name) { asm { load OpenSystemCallNum, r8 move filename, r9 syscall } } • The semantic of the syscall instruction is similar to a routine call instruction. • The difference is that (1) the syscall handler address is obtained from the system call/interrupt vector (table) maintained by the OS; and (2) the mode is changed to the system mode. Interrupt vector 0x0 0x1 . . “Open” handler OpenSystemCallNum

  12. System calls • Question: The purpose of a system call is to invoke the system call handler routine. Why use the system call, instead of the simple routine call? • A system call changes the execution mode into system mode. • Some instruction can only be executed under the system mode. • Some services can only be provided correctly by the operating system due to the concurrency.

  13. System calls • Typical sequence of events when running the syscall instruction: • Current program counter (PC) and program status word (PSW) are saved. • The program mode is changed to the system mode. • Hardware load PC from the system call interrupt vector location • Execute the system call interrupt handler • Change mode back to user mode • Restore PC and PSW and continue user program.

  14. System calls • System call interface • The system call interface is the description of the set of system calls supported by the OS. • The OS interface is pretty much defined by the system call interface. • Typical types of system calls • Process control • File management • Device management • Information management • Communication management

  15. Process A process is a program in execution. A process is a basic scheduling unit in an OS: during the execution, each process has a virtual machine. The execution of processes does not interference with one another. In a computer system, concurrency is realized by allowing multiple processes to co-exist at the same time. Most programs are single process programs and the OS hides the details about creation and termination of processes.

  16. Process .vs. Program Program: a collection of instructions Process: a running instance of the program, with additional states and system resources Example of additional states: process state (running, waiting, ready, etc) Example of system resources: memory.

  17. Process != Program Two processes can run the same program The code segment of two processes are the same program These two processes are totally independent of one another.

  18. Program != Process A program can create multiple processes Example: Internet Explorer

  19. Process context It takes more than the “executable” to run a program. Process context, sometimes also called process image, includes everything needed for the OS to run the program correctly. Program counter Stack pointer, etc

  20. Process context Contains all states necessary to run a program The information the process needs to do the job: code, data, stack, heap. This is known as User level context. MAX stack heap data text (code) 0 Process in memory

  21. User level context MAX (b, *p) - main (a) - foo stack … int aa; char buf[1000]; void foo() { int a; … } main() { int b; char *p; p = new char[1000]; foo(); } heap (p) (char[1000]) data (aa, buf) text (code) 0 Process memory

  22. Process context Contains all states necessary to run a program Is the user level context sufficient? Only if the system runs through one program at a time The system typically needs to switch back and forth between programs. P1 P2 R0 = 1 R0 = 2 R2 = R0 + 1 R2 = R0 • R2 in P1 is wrong. How to make • It correct? • Save R0 in P1 before switching • Restore R0 in P1 when switching from P2 to P1. • Registers should be a part of process context: the register context!

  23. Process context: User level context Code, data, stack, heap Register context (R0, R1,…, PC, stack pointer, PSW, etc). What else? OS resources. E.g open files, signal related data structures, etc. Process context

  24. Why is process context important? To run a process correctly, the process instructions must be executed within the process context!

  25. Where is the process context stored? User level context is in memory. Other context information is stored in a data structure called process control block. The OS has a process control block table. For each process, there is one entry in the table. Process control block also contains other information that the OS needs to manage the processes. Process status (running, waiting, etc) Process priority …… Process context

  26. Process Control Block (PCB)

  27. Process Environment • What happens when we execute a C program? ./a.out • How the command-line arguments are passed to the process? • Memory layout of a process

  28. What happens when we execute a C program? • int main(int argc, char *argv[]); • When a C program is executed by the kernel by one of the exec functions, a special start-up routine is called before the main function is called. • The executable program file specifies this routine as the starting address for the program; • This start-up routine takes values from the kernel the command-line arguments and the environment

  29. Memory Layout of C Program

  30. Memory Layout of C Program • Code - text segment • Initialized data – data segment • Uninitialized data – bss segment • Heap • Stack

  31. Memory Layout of C Program • Code - text segment • Machine instructions that the CPU executes • Sharable • Read-only

  32. Memory Layout of C Program • Initialized data – data segment • Variables initialized to non-zero values appearing outside any function causes this variable to be stored in the initialized data segment with its initial value. • Statically allocated and global data that are initialized with nonzero values live in the data segment

  33. Memory Layout of C Program • Uninitialized data – bss segment • BSS stands for ‘Block Started by Symbol’.  • Global and statically allocated data that initialized to zero by default are kept here

  34. Memory Layout • Stack • The stack segment is where local (automatic) variables are allocated.  • The data is popped up or pushed into the stack following the Last In First Out (LIFO) rule.  • When a function is called, a stack frame is created and PUSHed onto the top of the stack. • When a function returns, the stack frame is POPped from the stack. 

  35. Stack

  36. Heap • Heap • The heap is where dynamic memory (obtained by malloc(), calloc(), realloc()) comes from.  • It is typical for the heap to grow upward.  • It is located between un-initialized data and the stack.

  37. Environment Variables • Stored in process memory • Set of parameters that are inherited from parent process • Each program is also passed an environment list like the argument list. • Environment list is an array of character pointers, with each pointer containing the variable name and its value.

  38. Environment Variables

  39. Listing all arguments and environment vars int main (int argc, char *argv[]) { int i; char **ptr; extern char **environ; for (i = 0; i < argc; i++) /* echo all command-line args */ printf ("argv[%d]: %s\n", i, argv[i]); for (ptr = environ; *ptr != 0; ptr++) /* and all env strings */ printf ("%s\n", *ptr); exit (0); }

  40. Functions to access environment variables

  41. Process Control • Every process has a unique process ID, a non-negative integer. • Although unique, process IDs are reused. As processes terminate, their IDs become candidates for reuse. • Process ID 0 is usually the scheduler process and is often known as the swapper.

  42. Process Control • Init Process • Process ID 1 is usually the init process • This process is responsible for bringing up a UNIX system after the kernel has been bootstrapped. • The init process never dies. It is a normal user process. • init becomes the parent process of any orphaned child process

  43. Process Identifiers #include <unistd.h> • pid_t getpid(void); Returns: process ID of calling process • pid_t getppid(void); Returns: parent process ID of calling process • uid_t getuid(void);Returns: real user ID of calling process • uid_t geteuid(void);Returns: effective user ID of calling process • gid_t getgid(void);Returns: real group ID of calling process • gid_t getegid(void); Returns: effective group ID of calling process

  44. fork() • An existing process can create a new one by calling the fork function. #include <unistd.h> pid_t fork(void); Returns: 0 in child, process ID of child in parent, 1 on error • The new process created by fork is called the child process. This function is called once but returns twice. The only difference in the returns is that the return value in the child is 0, whereas the return value in the parent is the process ID of the new child

  45. fork() • Both the child and the parent continue executing with the instruction that follows the call to fork. • The child is a copy of the parent.

  46. copy-on-write (COW) • don't perform a complete copy of the parent's data, stack, and heap • These regions are shared by the parent and the child and have their protection changed by the kernel to read-only • If either process tries to modify these regions, the kernel then makes a copy of that piece of memory only, typically a "page" in a virtual memory system.

More Related