Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

Εργαστήριο Λειτουργικών Συστημάτων Μάθημα 6oυ Εξαμήνου, Τομέας Λογικού και Υπολογιστών Δρ. Α. Κομνηνός/Επ. Καθ. Χ. Μακρής akomninos@ceid.upatras.gr,

Παρόμοιες παρουσιάσεις


Παρουσίαση με θέμα: "Εργαστήριο Λειτουργικών Συστημάτων Μάθημα 6oυ Εξαμήνου, Τομέας Λογικού και Υπολογιστών Δρ. Α. Κομνηνός/Επ. Καθ. Χ. Μακρής akomninos@ceid.upatras.gr,"— Μεταγράφημα παρουσίασης:

1 Εργαστήριο Λειτουργικών Συστημάτων Μάθημα 6oυ Εξαμήνου, Τομέας Λογικού και Υπολογιστών
Δρ. Α. Κομνηνός/Επ. Καθ. Χ. Μακρής

2 Σύνοψη 6ης ∆ιάλεξης Λειτουργικό Σύστημα Minix Σύνοψη Μαθήματος
Οργάνωση του Λειτουργικού Συστήματος Οργάνωση πηγαίου κώδικα Minix recompilation Το System Task Σύνοψη Μαθήματος Επόμενη ∆ιάλεξη

3 find /usr/src -name file.c
grep -r “function_name” . cd /usr/src/tools make hdboot cd /usr/src make build Go to usc/src with #cd .. #make clean #make install Reboot with #shutdown –r ps -axlE

4 System Calls (1) Process Management Figure 1-9. The MINIX system calls. fd is a file descriptor; and n is a byte count, minix Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

5 System Calls (2) Signals Figure 1-9. The MINIX system calls. fd is a file descriptor; and n is a byte count. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

6 System Calls (3) File Management Figure 1-9. The MINIX system calls. fd is a file descriptor; and n is a byte count. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

7 System Calls (4) Dir. & File System Mgmt.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved System Calls (4) Dir. & File System Mgmt. Figure 1-9. The MINIX system calls. fd is a file descriptor; and n is a byte count. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

8 System Calls (5) Protection Figure 1-9. The MINIX system calls. fd is a file descriptor; and n is a byte count. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

9 System Calls (6) Time Management Figure 1-9. The MINIX system calls. fd is a file descriptor; and n is a byte count. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

10 The fork Call in the Shell
Figure A stripped-down shell. Throughout this book, TRUE is assumed to be defined as 1. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

11 Processes Figure Processes have three segments: text, data, and stack. In this example, all three are in one address space, but separate instruction and data space is also supported. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

12 System Calls for File Management (1)
Figure The structure used to return information for the stat and fstat system calls. In the actual code, symbolic names are used for some of the types. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

13 System Calls for File Management (2)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved System Calls for File Management (2) Figure A skeleton for setting up a two-process pipeline. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

14 System Calls for File Management (3)
Figure A skeleton for setting up a two-process pipeline. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

15 System Calls for Directory Management (1)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved System Calls for Directory Management (1) link(“/usr/jim/memo”,”/usr/ast/note”); Figure (a) Two directories before linking /usr/jim/memo to ast’s directory. (b) The same directories after linking. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

16 System Calls for Directory Management (2)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved System Calls for Directory Management (2) mount(“/dev/cdrom0”,”/mnt”,0); Figure (a) File system before the mount. (b) File system after the mount. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

17 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Process States Figure 2-2 A process can be in running, blocked, or ready state. Transitions between these states are as shown. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

18 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Process States Figure 2-3 The lowest layer of a process-structured operating system handles interrupts and scheduling. Above that layer are sequential processes. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

19 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Process Behavior (1) Figure Bursts of CPU usage alternate with periods of waiting for I/O. (a) A CPU-bound process. (b) An I/O-bound process. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

20 When to Schedule When scheduling is absolutely required:
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved When to Schedule When scheduling is absolutely required: 1. When a process exits. 2. When a process blocks on I/O, or a semaphore. When scheduling usually done (though not absolutely required) 1. When a new process is created. 2. When an I/O interrupt occurs. 3. When a clock interrupt occurs. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

21 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Priority Scheduling Figure A scheduling algorithm with four priority classes. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

22 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Scheduling in MINIX Figure The scheduler maintains sixteen queues, one per priority level. Shown here is the initial queuing process as MINIX 3 starts up. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

23 The Internal Structure of MINIX
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved The Internal Structure of MINIX Figure MINIX 3 is structured in four layers. Only processes in the bottom layer may use privileged (kernel mode) instructions. R Kernel R/W I/O ports, scheduling, message handling pm: starting stopping processes, signals fs: file system calls

24

25 Bootstrapping MINIX (1)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Bootstrapping MINIX (1) Figure Disk structures used for bootstrapping. (a) Unpartitioned disk. The first sector is the bootblock.

26 Bootstrapping MINIX (2)
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Bootstrapping MINIX (2) Figure Disk structures used for bootstrapping. (b) Partitioned disk. The first sector is the master boot record, also called masterboot.

27 Εκτέλεση ∆ιεργασιών
Οι διεργασίες εκτελούνται σειριακά ανά διαθέσιμο επεξεργαστή Μόνο μια διεργασία είναι ενεργή ανά πάσα στιγμή Οι πληροφορίες για κάθε διεργασία βρίσκονται: στο επίπεδο του πυρήνα, στον διαχειριστή διεργασιών και στον διαχειριστή αρχείων Το Λ.Σ. χρονοπρογραμματίζει τις διεργασίες – στο επίπεδο του πυρήνα και στον διαχειριστή διεργασιών

28 Κύκλος Ζωής ∆ιεργασιών
Τέσσερα βασικά γεγονότα οδηγούν στην δημιουργία νέων διεργασιών Αρχικοποίηση του συστήματος Μια διεργασία εκτελεί την κλήση συστήματος για την δημιουργία νέας διεργασίας ́Ενας χειριστής εκτελεί μια εντολή Εκκίνηση μιας εργασίας (batch job) Οι διεργασίες τερματίζουν εάν προκύψει ένας από τους παρακάτω λόγους Κανονικός τερματισμός – έξοδος Τερματισμός λόγω λάθους Απότομος τερματισμός Τερματισμός από μια άλλη διεργασία

29 Ιεράρχηση ∆ιεργασιών
́Οταν μια διεργασία δημιουργήσει μια νέα διεργασία (μέσω κάποιας κλήσης στο σύστημα) Θεωρούμε ότι υπάρχει σχέση γονέα – παιδιού Μια διεργασία παιδί μπορεί να δημιουργήσει και αυτή νέες διεργασίες ∆ημιουργείται μια ιεραρχία διεργασιών – ένα δένδρο Οι διεργασίες μπορούν να επικοινωνήσουν με τα κατώτερα επίπεδα του Λ.Σ. είτε αυτόνομα είτε ως ιεραρχία διεργασιών (ομάδα) π.χ. ένα σήμα παραδίδεται σε όλες τις διεργασίες Το Minix χρησιμοποιεί δύο ‘ειδικές’ διεργασίες που δημιουργούνται κατά την αρχικοποίησης του συστήματος Reincarnation Server και init δημιουργούν όλες τις άλλες διεργασίες του συστήματος

30 Reincarnation Server και init
Οι διεργασίες CLOCK και SYSTEM δεν είναι ορατές εξω από τον kernel H διεργασία Process Manager έχει PID 0 και δεν είναι ούτε παιδί ούτε πατέρας. Το init είναι η πρώτη διεργασία που εκτελείται κατά την αρχικοποίηση του συστήματος (PID 1) Εκτελεί τα scripts που βρίσκονται στον φάκελο /etc/rc μέσω του reincarnation server (o server αυτός εκινείται μέσα από ένα από τα scripts) Η βασική λειτουργία του reincarnation server (rs) είναι η εκκίνηση των servers και των οδηγών (device drivers) Επομένως όλοι οι servers και οι οδηγοί είναι ‘παιδιά’ του rs Αν κάποια διεργασία τερματίσει τότε θα ειδοποιηθεί ο rs Παρακολουθεί την εκτέλεση του και αν διαπιστώσει κάποιο πρόβλημα έχει το δικαίωμα να επανεκκινησει την διεργασία Με αυτόν τον τρόπο το Minix προσφέρει λειτουργίες αυτο-ίασης Η τελευταία διεργασία που ξεκινάει η init είναι η getty που είναι υπεύθυνη για τις κονσόλες των χειριστών Kernel, process manager and all under init

31 MINIX 3 Startup Figure 2-30. Some important MINIX 3 system components.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved MINIX 3 Startup Figure Some important MINIX 3 system components. Others such as an Ethernet driver and the inet server may also be present.

32 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved MINIX Memory (1) Figure Memory layout after MINIX 3 has been loaded from the disk into memory. The kernel, servers, and drivers are independently compiled and linked programs, listed on the left. Sizes are approximate and not to scale. top half Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

33 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved MINIX Memory (2) Figure Memory layout after MINIX 3 has been loaded from the disk into memory. The kernel, servers, and drivers are independently compiled and linked programs, listed on the left. Sizes are approximate and not to scale.

34 Image ramdisk The ramdisk itself is build within the src/drivers/ramdisk directory. The image ramdisk contains several drivers which are used to boot the system fully: Package Source On ramdisk Comments at_wini src/drivers/at_wini bin/at_wini bios_wini src/drivers/bios_wini bin/bios_wini floppy src/drivers/floppy bin/floppy pci src/drivers/pci bin/pci Usually needed by the at_wini driver Minix File System service src/servers/mfs sbin/mfs For the real root file system Ext2 File System service src/servers/ext2 sbin/ext2 If real root is using EXT2 (Linux)

35 Needed for running service src/drivers/memory/ramdisk/rc etc/rc
It also needs several commands, to perform the initialization – and several support files Package Source On ramdisk Comments cdprobe src/commands/cdprobe/cdprobe.c bin/cdprobe loadramdisk src/commands/simple/loadramdisk.c bin/loadramdisk ash src/commands/ash/* bin/sh service src/servers/rs/service.c bin/service sysenv src/commands/simple/sysenv.c bin/sysenv Package Source On ramdisk Comments Access Control List src/etc/system.conf etc/system.conf src/etc/mtab etc/mtab Empty file src/etc/passwd etc/passwd Needed for running service src/drivers/memory/ramdisk/rc etc/rc Actual instructions

36 MINIX Message Types Figure 2-34. The seven message types used in
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved MINIX Message Types Figure The seven message types used in MINIX 3. The sizes of message elements will vary, depending upon the architecture of the machine; this diagram illustrates sizes on CPUs with 32-bit pointers, such as those of Pentium family members. (/usr/src/include/minix/ipc.h and /usr/src/include/minix/com.h) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

37

38 Implementation of EXIT
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved (a) (b) Figure (a) The situation as process 12 is about to exit. (b) The situation after it has exited.

39 Εκτέλεση ∆ιεργασιών
Οι διεργασίες είναι ανεξάρτητες οντότητες Μπορούν να αλληλεπιδράσουν μεταξύ τους, να επικοινωνήσουν και να συγχρονιστούν cat chapter1 chapter2 | grep tree Η grep είναι έτοιμη να ‘τρέξει’ όμως περιμένει είσοδο από την cat Επομένως μια διεργασία μπλοκάρει επειδή δεν μπορεί να συνεχίσει την εκτέλεση της Υπάρχουν τέσσερις πιθανοί τρόποι μετάβασης μεταξύ των καταστάσεων μιας διεργασίας:

40 Υλοποίηση ∆ιεργασιών
Η υλοποίηση του μοντέλου των διεργασιών βασίζεται στην διατήρηση του ‘πίνακα στοιχείων διεργασιών’ (process table) Περιέχει μια εγγραφή για κάθε διεργασία Η διαχείριση των διεργασιών δεν γίνεται σε ένα σημείο Ορισμένες λειτουργίες διαχείρισης γίνεται στο επίπεδο του πυρήνα Κάποιες άλλες λειτουργίες γίνονται από τον διαχειριστή διεργασιών και τον διαχειριστή αρχείων ́Αρα δεν υπάρχει ένας πίνακας αλλά τρεις !

41 Πίνακες Στοιχείων ∆ιεργασιών (proc.h)
Kernel Process management File management Registers Pointer to text segment UMASK mask Program counter Pointer to data segment Root directory Program status word Pointer to bss segment Working directory Stack pointer Exit status File descriptors Process state Signal status Real id Current scheduling priority Process ID Effective UID Maximum scheduling priority Parent process Real GID Scheduling ticks left Process group Effective GID Quantum size Children's CPU time Controlling tty CPU time used Real UID Save area for read/write Message queue pointers System call parameters Pending signal bits Various flag bits Process name File info for sharing text Bitmaps for signals

42 Γενικά περί System Task
Οι βασικές συνιστώσες του Minix είναι ανεξάρτητες διεργασίες Εκτελούνται εκτός του πυρήνα ∆εν έχουν άμεση πρόσβαση στους πίνακες του πυρήνα ∆εν επιτρέπεται να χειριστούν τις μονάδες εισόδου/εξόδου Παράδειγμα: Η κλήση συστήματος fork υλοποιείται από τον διαχειριστή διεργασιών ́Οταν δημιουργείται μια νέα διεργασία, πρέπει να ενημερωθεί ο πυρήνας – για λόγους χρονοπρογραμματισμού Πώς μπορεί να επικοινωνήσει ο διαχειριστής διεργασιών με τον πυρήνα ; Λύση: Υλοποίηση του System Task Ο πυρήνας προσφέρει μια ομάδα υπηρεσιών προς τους οδηγούς και τους διαχειριστές για την πρόσβαση στους πίνακες του πυρήνα, χειρισμό εισόδων/εξόδων κλπ. Αυτές οι υπηρεσίες δεν είναι προσβάσιμες από απλές διεργασίες

43 Σκοπός του System Task (1)
Το System Task είναι compiled μαζί με τον πυρήνα του συστήματος (δηλ. ίδιο εκτελέσιμο) Στην πραγματικότητα είναι διαφορετική διεργασία και χρονοπρογραμματίζεται διαφορετικά Ο σκοπός του System Task είναι η εξυπηρέτηση αιτήσεων για πρόσβαση στις ειδικές υπηρεσίες του πυρήνα Αποκλειστικά προς τους οδηγούς και τους διαχειριστές Στα Λ.Σ. με μονολιθικό πυρήνα, ο όρος ‘Κλήση Συστήματος’ αναφέρεται σε όλες τις υπηρεσίες που προσφέρει ο πυρήνας Στα σύγχρονα Λ.Σ., το πρότυπο POSIX περιγράφει τις ελάχιστες κλήσεις συστήματος που προσφέρει ο πυρήνας Μπορεί να προσφέρει επεκτάσεις στο πρότυπο, υλοποιώντας μια συλλογή συναρτήσεων που είναι πιο εύχρηστες και πιο κατανοητές

44 1: System call 2: IPC 3: Kernel call 6: Kernel call 9: Kernel call
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

45 Σκοπός του System Task (2)
Επίσης, στα μονολιθικά Λ.Σ., όλες οι κλήσεις του συστήματος και οι επεκτάσεις Φαίνονται σαν διαφορετικές βιβλιοθήκες Είναι μέρος του πυρήνα Στα Λ.Σ. με μικρο-πυρήνα -- Minix Συνιστώσες του Λ.Σ. που υλοποιούν βασικές κλήσεις του συστήματος (system calls) εκτελούνται εκτός πυρήνα Εξακολουθούμε να χρησιμοποιούμε τον όρο ‘κλήση συστήματος POSIX ’ Αυτό όμως από μόνο του δεν αρκεί για να καταλάβουμε το σημείο που υλοποιείται η κλήση Και εφόσον ορισμένες υλοποιούνται εκτός πυρήνα – δεν αρκεί για να αποκτήσουν άμεση πρόσβαση στις πληροφορίες του πυρήνα

46 Οργάνωση του System Task
κάθε ένα από αυτά μπορεί να θεωρηθεί μια κλήση του πυρήνα Σε ορισμένες περιπτώσεις ο ίδιος τύπος μηνύματος εμφανίζεται με διαφορετικά ονόματα με την χρήση macros Σε άλλες περιπτώσεις μια συγκεκριμένη συνάρτηση επεξεργάζεται διαφορετικούς τύπους μηνυμάτων Η βασική δομή του System Task είναι απλή (αρχείο kernel/system.c) Αρχικοποιεί τις εσωτερικές δομές (συνάρτηση initialize) Εκτελεί ένα ατέρμονο βρόγχο (συνάρτηση sys_task) ∆έχεται νέα μηνύματα Εκτελεί τις αντίστοιχες συναρτήσεις Απαντάει με τα αποτελέσματα Περιέχει ορισμένες βοηθητικές συναρτήσεις

47 Κλήσεις Πυρήνα (1) Οι κλήσεις του πυρήνα μπορούν να κατηγοριοποιηθούν σύμφωνα με τον διαχειριστή που τις καλεί από τις ακόλουθες κλήσεις, οι sys_fork, sys_exec, sys_exit, sys_trace αντιστοιχούν σε κλήσεις συστήματος που ορίζει το POSIX η sys_nice δεν ορίζεται από το POSIX ∆.∆. = ∆ιαχειριστής ∆ιεργασιών (process manager)

48 Κλήσεις Πυρήνα (2) Η κλήση sys_privctl χρησιμοποιείται από τον Reincarnation Server είναι ο διαχειριστής που είναι υπεύθυνος για την μετατροπή ‘απλών’ διεργασιών σε διεργασίες τους συστήματος Η sys_privctl αλλάζει τα δικαιώματα μιας διεργασίας για να μπορεί να κάνει κλήσεις στον πυρήνα Χρησιμοποιείται όταν εκτελεστεί ένας οδηγός εισόδου / εξόδου και κάποιος διαχειριστής δεν βρίσκεται στο image του συστήματος – δηλ. δεν φορτώνεται απ ́ευθείας κατά την εκκίνηση του συστήματος για δεύτερη φορά (λόγω προβλήματος)

49 Κλήσεις Πυρήνα (3) Οι ακόλουθες κλήσεις του πυρήνα έχουν σχέση με τα σήματα Σ.Α. = Σύστημα Αρχείων / ∆ιαχειριστής Αρχείων (file system / file manager) TTY -- Κονσόλα / Τερματικό

50 Κλήσεις Πυρήνα (4) Αυτή η κατηγορία κλήσεων του πυρήνα είναι ιδιαιτερότητα του Minix Προσφέρουν πρόσβαση στους οδηγούς εισόδου/εξόδου

51 Κλήσεις Πυρήνα (5) Οι ακόλουθες κλήσεις του πυρήνα έχουν σχέση με την διαχείριση της μνήμης

52 Κλήσεις Πυρήνα (6) Η κλήση sys_times αντιστοιχεί στην κλήση του συστήματος times που ορίζει το POSIX Η κλήση sys_alarm έχει ‘κάποια’ σχέση με την κλήση του συστήματος alarm που ορίζει το POSIX -- δεν έχει σχέση με τη λειτουργία κουδουνιού που προσφέρεται στις απλές διεργασίες Η κλήση sys_alarm μπορεί να κληθεί από τον ∆.∆. όταν αντιμετωπιστεί σοβαρό πρόβλημα, ή από τον χειριστή όταν πατήσει CTRL-ALT-DEL

53 ΔΗΜΙΟΥΡΓΙΑ KERNEL CALL (http://wiki. minix3
kernel call means that a request is sent to a kernel where it is handled by one of the kernel tasks. The details of assembling a request message, sending it to the kernel and awaiting the response are conveniently hidden in a system library. The header file of this library is src/include/minix/syslib.h and its implementation is found in src/lib/libsys. The actual implementation of the kernel calls is defined in the SYSTEM kernel task. Suppose that a program makes a sys_call() system call. By convention, this call is transformed into a request message with type SYS_CALL that is sent to the kernel task SYSTEM. The SYSTEM task handles the request in a function named do_call() and returns the result. The mapping of kernel call numbers and handler functions is done during the SYSTEM task's initialization response. src/kernel/system.c. The prototypes of the handler functions are declared in src/kernel/system.h. Their implementation is contained in separate files in the directory src/kernel/system/. These files are compiled into the library /src/kernel/system/system.a that is linked to the kernel. The kernel call numbers and their request and response parameters are defined in src/include/minix/com.h. Kernel calls all start with SYS_and all parameters that belong to the same kernel call share a common prefix.

54 Δημιουργία νέου system call
usr/src/include/minix/callnr.h : Επιλέγουμε έναν αριθμό για το νέο system call που δεν χρησιμοποιείται από κάποιο άλλο (π.χ. 69) και δίνουμε ένα κατάλληλο όνομα (π.χ. #define MYCALL 69) /usr/src/servers/ΧΧΧΧ/table.c : Αφού το system call αφορά κάποιον server, τροποποιούμε το σχετικό αρχείο table.cπροσθέτοντας στην κατάλληλη θέση την συνάρτηση handler (π.χ. do_mycall) /usr/src/servers/vfs/proto.h Προσθέτουμε το πρωτότυπο της συνάρτησης handler στο αρχείο αυτό (π.χ. _PROTOTYPE( int do_mycall, (void) );) /usr/src/servers/XXX/XYZ.c Μπορούμε να προσθέσουμε τη συνάρτηση του call handler (do_mycall()) σε κάποιο ήδη υπάρχον αρχείο ή να την βάλουμε σε κάποιο καινούριο. Αν ο handler είναι τροποποίηση ενός ήδη υπάρχοντος, το πιο εύκολο είναι να τον προσθέσουμε στο σχετικό υπάρχον αρχείο. Προσθήκη βοηθητικής συνάρτησης σε φάκελο /usr/src/lib/libc/sys-minix (3.2.1) ή /usr/src/lib/libc/posix (3.1.7)). λ.χ. στο /usr/src/lib/libc/sys-minix κοιτάξτε τα αρχεία chown.c και chdir.c που περιέχουν σχετικές βοηθητικές συναρτήσεις (αρκετά ενδιαφέρον το σχετικό link σε αντίστοιχο πανεπιστημιακό μάθημα πανεπιστημίου του εξωτερικού (CISE-florida) )

55 ∆ομή κώδικα του System Task
Το System Task υλοποιείται από το system.h και system.c Τα αρχεία είναι στον φάκελο /usr/src/kernel Το Minix δεν είναι μόνο για γενική χρήση Στοχεύει και σε ενσωματωμένα συστήματα Επιτρέπει την ενεργοποίηση/απενεργοποίηση των κλήσεων του πυρήνα – μείωση μεγέθους εκτελέσιμου Το αρχείο kernel/config.h ορίζει ποιες κλήσεις είναι ενεργές Αν αφαιρέσουμε μια δήλωση, όλα τα τμήματα του κώδικα που σχετίζονται με την συγκεκριμένη κλήση δεν θα γίνουν compile #define USE_FORK 1 // fork a new process #define USE_NEWMAP 1 // set a new memory map #define USE_EXEC 1 // update process after execute #define USE_EXIT 1 // clean up after process exit #define USE_NICE 1 // change scheduling priority

56 Ορισμός Κλήσεων Πυρήνα
́Ολες οι κλήσεις του πυρήνα ορίζονται στο αρχείο com.h Βρίσκεται στον φάκελο /usr/src/include/minix Αν θέλουμε να προσθέσουμε μια νέα κλήση, πρέπει να την ορίσουμε εδώ Ανεξάρτητα από το αν θα την απενεργοποιήσουμε ή όχι #define KERNEL_CALL 0x600 // base for kernel calls // to SYSTEM #define SYS_FORK (KERNEL_CALL + 0) // sys_fork() #define SYS_EXEC (KERNEL_CALL + 1) // sys_exec() #define SYS_EXIT (KERNEL_CALL + 2) // sys_exit() #define SYS_NICE (KERNEL_CALL + 3) // sys_nice() #define NR_SYS_CALLS 28 // number of system calls

57 Αρχείο Επικεφαλίδας System Task
Το αρχείο /usr/src/kernel/system.h ορίζει τις συναρτήσεις που χειρίζονται κάθε κλήση του πυρήνα Για την κλήση sys_xxx αντιστοιχεί την συνάρτηση do_xxx Η συνάρτηση do_unused είναι μια ‘κενή’ συνάρτηση Η συνάρτηση do_copy αντιστοιχεί επίσης στις κλήσεις sys_vircopy, sys_physcopy /* Default handler for unused kernel calls. */ _PROTOTYPE( int do_unused, (message *m_ptr) ); _PROTOTYPE( int do_exec, (message *m_ptr) ); _PROTOTYPE( int do_fork, (message *m_ptr) ); _PROTOTYPE( int do_trace, (message *m_ptr) ); _PROTOTYPE( int do_nice, (message *m_ptr) ); _PROTOTYPE( int do_copy, (message *m_ptr) ); #define do_vircopy do_copy #define do_physcopy do_copy

58 Αντιστοίχηση Συναρτήσεων – Κλήσεις Πυρήνα
Για την αντιστοίχιση συναρτήσεων με κλήσεις συστήματος, στο system.c ορίζεται ο πίνακας call_vec[] Ανατρέχουμε στον πίνακα με βάση τον αριθμό της κλήσης (όπως ορίζεται στο μήνυμα) – αυτή η τεχνική χρησιμοποιείται και σε άλλα σημεία του Minix Προσθέτουμε στοιχεία στον πίνακα με την χρήση του macro map Αν προσπαθήσουμε να αντιστοιχήσουμε μια συνάρτηση σε μια κλήση που δεν υπάρχει, το macro επιστρέφει ένα πίνακα με αρνητικό μέγεθος ο compiler θα βγάλει λάθος PUBLIC int (*call_vec[NR_SYS_CALLS])(message *m_ptr); #define map(call_nr, handler) \ {extern int dummy[NR_SYS_CALLS>(unsigned)(call_nr-KERNEL_CALL) ? 1:-1];} \ call_vec[(call_nr-KERNEL_CALL)] = (handler)

59 Αρχικοποίηση System Task
Η αρχικοποίηση γίνεται με την συνάρτηση initialize (αρχείο system.c) Αρχικά αντιστοιχεί σε όλες τις κλήσεις του πυρήνα την συνάρτηση do_unused (κενή συνάρτηση) Στην συνέχεια αντιστοιχεί μια προς μια τις συναρτήσεις PRIVATE void initialize(void){ for (i=0; i<NR_SYS_CALLS; i++) call_vec[i] = do_unused; /* Process management. */ map(SYS_FORK, do_fork); map(SYS_EXEC, do_exec); map(SYS_EXIT, do_exit); map(SYS_NICE, do_nice); ... }

60 Βασική Λειτουργία του System Task
Η βασική λειτουργία ορίζεται στην συνάρτηση sys_task Ατέρμων βρόχος PUBLIC void sys_task(){ static message m; register int result; register struct proc *caller_ptr; unsigned int call_nr; int s; /* Initialize the system task. */ initialize(); while (TRUE) { ... }

61 Βασικός Βρόγχος System Task
Η συνάρτηση priv ελέγχει αν η διεργασία αποστολέας έχει πρόσβαση στην συγκεκριμένη κλήση του πυρήνα while (TRUE) { // Get work. Block until a message arrives receive(ANY, &m); call_nr = (unsigned) m.m_type - KERNEL_CALL; caller_ptr = proc_addr(m.m_source); /* See if the caller made a valid request and try to handle it. */ if (! (priv(caller_ptr)->s_call_mask & (1<<call_nr))) { kprintf("SYSTEM: request %d from %d denied.\n", call_nr,m.m_source); result = ECALLDENIED; /* illegal message type */ } else if (call_nr >= NR_SYS_CALLS) { /* check call number */ kprintf("SYSTEM: illegal request %d from %d.\n", call_nr,m.m_source); result = EBADREQUEST; /* illegal message type */ } else result = (*call_vec[call_nr])(&m); /* handle the kernel call */ if (result != EDONTREPLY) m.m_type = result; /* report status of call */ if (OK != (s=lock_send(m.m_source, &m))) kprintf("SYSTEM, reply to %d failed: %d\n", m.m_source, s);

62 Adding a System Call in Minix
usr/src/include/minix/callnr.h : Επιλέγουμε έναν αριθμό για το νέο system call που δεν χρησιμοποιείται από κάποιο άλλο (π.χ. 69) και δίνουμε ένα κατάλληλο όνομα (π.χ. #define MYCALL 69) /usr/src/servers/ΧΧΧΧ/table.c : Αφού το system call αφορά κάποιον server, τροποποιούμε το σχετικό αρχείο table.c προσθέτοντας στην κατάλληλη θέση την συνάρτηση handler (π.χ. do_mycall) /usr/src/servers/vfs/proto.h Προσθέτουμε το πρωτότυπο της συνάρτησης handler στο αρχείο αυτό (π.χ. _PROTOTYPE( int do_mycall, (void) );) /usr/src/servers/XXX/XYZ.c Μπορούμε να προσθέσουμε τη συνάρτηση του call handler (do_mycall()) σε κάποιο ήδη υπάρχον αρχείο ή να την βάλουμε σε κάποιο καινούριο. Αν ο handler είναι τροποποίηση ενός ήδη υπάρχοντος, το πιο εύκολο είναι να τον προσθέσουμε στο σχετικό υπάρχον αρχείο.

63 Τροποποίηση εντολής shell για να δεχθεί το νέο system call
/usr/src/commands/ash/XXX.c Εντοπίζουμε το αρχείο που περιέχει τον κώδικα της εντολής που θέλουμε να τροποποιήσουμε ώστε να τρέχει το νέο system call. Πιθανότατα η εντολή χρησιμοποιεί κάποια άλλη βοηθητική συνάρτηση. Αν όχι, τροποποιούμε την κλήση προς την _syscall στο τρέχον αρχείο. Αλλιώς πάμε στο επόμενο βήμα. Στην περίπτωση που ο κώδικας της εντολής στο προηγούμενο βήμα χρησιμοποιεί άλλη βοηθητική συνάρτηση που καλεί την _syscall, την εντοπίζουμε και την αντιγράφουμε εντός του ίδιου αρχείου δίνοντας ένα νέο όνομα (δεν τροποποιούμε την ίδια την συνάρτηση γιατί μπορεί να χρησιμοποιείται και από άλλες λειτουργίες που δεν θέλουμε να επιρρεάσουμε). Στην νέα συνάρτηση, τροποποιούμε την κλήση προς την _syscall κατάλληλα ώστε να καλεί το νέο system call που έχουμε δημιουργήσει. Επίσης αν η συνάρτηση υπάρχει μέσα σε κάποιο .h αρχείο, βάζουμε και την κεφαλίδα της νέας συνάρτησης. Τροποποιούμε τον κώδικα της εντολής του βήματος 5 (/usr/src/commands/ash/XXX.c) ώστε να καλεί την νέα βοηθητική συνάρτηση. Αλλάζουμε directory σε /usr/src/ και δίνουμε την εντολή make world. Οδηγίες για τμηματικό compilation και εγκατάσταση ενημερώσεων στο minix υπάρχουν στο master makefile

64 Σύνοψη Μαθήματος Το System Task στο Minix 3 Επισκόπηση Σκοπός
∆ομή – Οργάνωση Υλοποίηση

65 Βιβλιογραφία Βιβλίο ‘‘Operating Systems Design and Implementation, Third Edition’’ (Andrew S. Tanenbaum) Κεφάλαιο 1: Εισαγωγή Παράγραφος 1.4 System Calls Παράγραφος 1.5 Operating System Structure Κεφάλαιο 2: Processes Βιβλίο ‘Σύγχρονα Λειτουργικά Συστήματα’ (A.Tanenbaum) Κεφάλαιο 1: Εισαγωγή Παράγραφος 1.6 Κλήσεις Συστήματος Παράγραφος 1.7 Η ∆ομη των Λειτουργικών Συστημάτων Κεφάλαιο 2: ∆ιεργασίες Κεφάλαιο 10: Μελέτη Περίπτωσης 1: Unix και Linux Παράγραφος 10.3 Οι ∆ιεργασίες στο UNIX

66 Processes in Memory (1) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure (a) A process in memory. (b) Its memory representation for combined I and D space. (c) Its memory representation for separate I and D space Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

67 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Processes in Memory (2) Figure (a) The memory map of a separate I and D space process, as in the previous figure. (b) The layout in memory after a second process starts, executing the same program image with shared text. (c) The memory map of the second process.

68 The Hole List Figure 4-35. The hole list is an array of struct hole.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure The hole list is an array of struct hole.

69 FORK System Call Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure The steps required to carry out the fork system call.

70 EXEC System Call (1) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure The steps required to carry out the exec system call.

71 EXEC System Call (2) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure (a) The arrays passed to execve. (b) The stack built by execve. (c) The stack after relocation by the PM. (d) The stack as it appears to main at start of execution.

72 EXEC System Call (3) Figure 4-39. The key part of crtso,
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure The key part of crtso, the C run-time, start-off routine.

73 Signal Handling (1) Figure 4-40. Three phases of dealing with signals.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure Three phases of dealing with signals.

74 Signal Handling (2) Figure 4-41. The sigaction structure.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure The sigaction structure.

75 Signal Handling (3) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure Signals defined by POSIX and MINIX 3. Signals indicated by (*) depend on hardware support. Signals marked (M) not defined by POSIX, but are defined by MINIX 3 for compatibility with older programs. Signals kernel are MINIX 3 specific signals generated by the kernel, and used to inform system processes about system events. Several obsolete names and synonyms are not listed here.

76 Signal Handling (4) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure Signals defined by POSIX and MINIX 3. Signals indicated by (*) depend on hardware support. Signals marked (M) not defined by POSIX, but are defined by MINIX 3 for compatibility with older programs. Signals kernel are MINIX 3 specific signals generated by the kernel, and used to inform system processes about system events. Several obsolete names and synonyms are not listed here.

77 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Signal Handling (5) Figure A process’ stack (above) and its stackframe in the process table (below) corresponding to phases in handling a signal. (a) State as process is taken out of execution. (b) State as handler begins execution. (c) State while sigreturn is executing. (d) State after sigreturn completes execution.

78 Initialization of Process Manager
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure Boot monitor display of memory usage of first few system image components.

79 Implementation of EXIT
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved (a) (b) Figure (a) The situation as process 12 is about to exit. (b) The situation after it has exited.

80 Implementation of EXEC
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure (a) Arrays passed to execve and the stack created when a script is executed. (b) After processing by patch_stack, the arrays and the stack look like this. The script name is passed to the program which interprets the script.

81 Signal Handling (1) Figure 4-47. System calls relating to signals.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure System calls relating to signals.

82 Signal Handling (2) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure Messages for an alarm. The most important are: (1) User does alarm. (4) After the set time has elapsed, the signal arrives. (7) Handler terminates with call to sigreturn. See text for details.

83 Signal Handling (3) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure The sigcontext and sigframe structures pushed on the stack to prepare for a signal handler. The processor registers are a copy of the stackframe used during a context switch.

84 Other System Calls (1) Figure 4-50. Three system calls involving time.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure Three system calls involving time. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

85 Other System Calls (2) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure The system calls supported in servers/pm/getset.c. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

86 Other System Calls (3) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure Special-purpose MINIX 3 system calls in servers/pm/misc.c. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

87 Other System Calls (4) Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Figure Debugging commands supported by servers/pm/trace.c.

88 Memory Management Utilities
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved Three entry points of alloc.c alloc_mem – request a block of memory of given size free_mem – return memory that is no longer needed mem_init – initialize free list when PM starts running


Κατέβασμα ppt "Εργαστήριο Λειτουργικών Συστημάτων Μάθημα 6oυ Εξαμήνου, Τομέας Λογικού και Υπολογιστών Δρ. Α. Κομνηνός/Επ. Καθ. Χ. Μακρής akomninos@ceid.upatras.gr,"

Παρόμοιες παρουσιάσεις


Διαφημίσεις Google