Download Operating System Structures-Operating Systems-Lecture Notes and more Study notes Operating Systems in PDF only on Docsity!
Operating Systems [CS-604] Lecture No. 4
Operating Systems
Lecture No. 4
Reading Material
Operating Systems Structures, Chapter 3 PowerPoint Slides for Lecture 3
Summary
Operating system structures Operating system design and implementation UNIX/Linux directory structure Browsing UNIX/Linux directory structure
Operating Systems Structures (continued)
Layered Approach The modularization of a system can be done in many ways. As shown in Figure 4.1, in the layered approach the OS is broken up into a number of layers or levels each built on top of lower layer. The bottom layer is the hardware; the highest layer (layer N) is the user interface. A typical OS layer (layer-M) consists of data structures and a set of routines that can be invoked by higher-level layers. Layer M in turn can invoke operations on lower level layers.
Figure 4.1 The layered structure
The main advantage of the layered approach is modularity. The layers are selected such that each uses functions and services of only lower layers. This approach simplifies debugging and system verification. The major difficulty with layered approach is careful definition of layers, because a layer can only use the layers below it. Also it tends to be less efficient than other approaches. Each layer adds overhead to a system call (which is trapped when the
program executes a I/O operation, for instance). This results in a system call that takes longer than does one on a non-layered system. THE operating system by Dijkstra and IBMโs OS/2 are examples of layered operating systems.
Micro kernels This method structures the operating system by removing all non-essential components from the kernel and implementing as system and user level programs. The result is a smaller kernel. Micro kernels typically provide minimum process and memory management in addition to a communication facility. The main function of the micro kernel is to provide a communication facility between the client program and the various services that are also running in the user space. The benefits of the micro kernel approach include the ease of extending the OS. All new services are added to user space and consequently do not require modification of the kernel. When the kernel does have to be modified, the changes tend to be fewer because the micro kernel is a smaller kernel. The resulting OS is easier to port from one hard ware design to another. It also provides more security and reliability since most services are running as user rather than kernel processes. Mach, MacOS X Server, QNX, OS/2, and Windows NT are examples of microkernel based operating systems. As shown in Figure 4.2, various types of services can be run on top of the Windows NT microkernel, thereby allowing applications developed for different platforms to run under Windows NT.
Figure 4.2 Windows NT client-server structure
Virtual Machines Conceptually a computer system is made up of layers. The hardware is the lowest level in all such systems. The kernel running at the next level uses the hardware instructions to create a set of system call for use by outer layers. The system programs above the kernel are therefore able to use either system calls or hardware instructions and in some ways these programs do not differentiate between these two. System programs in turn treat the hardware and the system calls as though they were both at the same level. In some systems the application programs can call the system programs. The application programs view everything under them in the hierarchy as though the latter were part of the machine itself. This layered approach is taken to its logical conclusion in the concept of a virtual machine (VM). The VM operating system for IBM systems is the best example of VM concept. By using CPU scheduling and virtual memory techniques an operating system can create the illusion that a process has its own memory with its own (virtual) memory. The
Figure 4.4 Java Virtual Machine
System Design and Implementation
Design Goals At the highest level, the deign of the system will be affected by the choice of hardware and type of system: batch , time shared, single user, multi user, distributed , real time or general purpose. Beyond this highest level, the requirements may be much harder to specify. The requirements can be divided into much two basic groups: user goal and system goals. Users desire a system that is easy to use, reliable, safe and fast. People who design, implement and operate the system, require a system that is easy to design, implement and maintain. An important design goal is separation of mechanisms and policies. Mechanism: they determine how to do something. A general mechanism is more desirable. Example: CPU protection. Policy: determine what will be done. Example: Initial value in the counter used for CPU protection. The separation of policy and mechanism is important for flexibility, as policies are likely to change across places or over time. For example, the system administrator can set the initial value in counter before booting a system.
Implementation Once an operating system is designed, it must be implemented. Traditionally operating systems have been written in assembly language. Now however they are written in higher-level languages such as C/ C++ since these allow the code to be written faster, more compact, easier to understand and easier to port.
UNIX/LINUX Directory Structure
Dennis Ritchie and Ken Thomsom wrote UNIX at the Bell Labs in 1969. It was initially written in assembly language and a high-level language called Bit was later converted from B to C language. Linus Torvalds, an undergraduate student at the University of
Helsinki, Finland, wrote Linux in 1991. It is one of the most popular operating systems, certainly for PCs. UNIX has a hierarchical file system structure consisting of a root directory (denoted as /) with other directories and files hanging under it. Unix uses a directory hierarchy that is commonly represented as folders. However, instead of using graphical folders typed commands (in a command line user interface) are used to navigate the system. Particular files are then represented by paths and filenames much like they are in html addresses. A pathname is the list of directories separated by slashes (/). If a pathname starts with a /, it refers to the root directory. The last component of a path may be a file or a directory. A pathname may simply be a file or directory name. For example, /usr/include/sys/param.h, ~/courses/cs604, and prog1.c are pathnames. When you log in, the system places you in a directory called your home directory (also called login directory ). You can refer to your home directory by using the ~ or $PATH in Bash, Bourne shell, and Korn shells and by using $path in the C and TC shells. Shells also understand both relative and absolute pathnames. An absolute pathname starts with the root directory (/) and a relative pathname starts with your home directory, your current directory, or the parent of your current directory (the directory that you are currently in). For example, /usr/include/sys/param.h is an absolute pathname and ~/courses/cs604 and prog1.c are relative pathnames. You can refer to your current directory by using. (pronounced dot) and the parent of your current directory by using .. (pronounced dotdot). For example, if nadeem is currently in the courses directory, he can refer to his home directory by using .. and his personal directory by using ../personal. Similarly, he can refer to the directory for this course by using cs604. Figures 4.5 and 4.6 show sample directory structures in a UNIX/Linux system. The user nadeem has a subdirectory under his home directory, called courses. This directory contains subdirectories for the courses that you have taken, including one for this course.
Figure 4.5 UNIX/Linux directory hierarchy Figure 4.6 Home directories of students
bin dev home sbin usr
faculty (^) โฆ students
โฆ
student
ali nadeem munir
personal courses
cs401 cs
libraries can be dynamically linked which makes them very similar to DLL files in the Windows environment.
/lost+found This is the directory where Linux keeps files that are restored after a crash or when a partition hasn't been unmounted properly before a shutdown.
/mnt Used for mounting temporary filesystems. Filesystems can be mounted anywhere but the /mnt directory provides a convenient place in the Linux directory structure to mount temporary file systems.
/opt Often used for storage of large applications packages
/proc This is a special, "virtual" directory where system processes are stored. This directory doesn't physically exist but you can often view (or read) the entries in this directory.
/root The home directory for the superuser (root). Not to be confused with the root (/) directory of the Linux file system.
/sbin Utilities used for system administration (halt, ifconfig, fdisk, etc.) are stored in this directory. /usr/sbin, and /usr/local/sbin are other directories that are used for this purpose as well. /sbin/init.d are scripts used by /sbin/init to start the system.
/tmp Used for storing temporary files. Similar to C:\Windows\Temp.
/usr Typically a shareable, read-only directory. Contains user applications and supporting files for those applications. /usr/X11R6 is used by the X Window System. /usr/bin contains user accessible commands. /usr/doc holds documentation for /usr applications. /usr/include this directory contains header files for the C compiler. /usr/include/g++ contains header files for the C++ compiler. /usr/lib libraries, binaries, and object files that aren't usually executed directly by users. /usr/local used for installing software locally that needs to be safe from being overwritten when system software updates occur. /usr/man is where the manual pages are kept. /usr/share is for read-only independent data files. /usr/src is used for storing source code of applications installed and kernel sources and headers.
/var This directory contains variable data files such as logs ( /var/log ), mail ( /var/mail ), and spools ( /var/spool ) among other things.
(Source: http://www.chrisshort.net/archives/2005/01/linux-directory-structure.php)
