Discussions

Discussion # 6

Operating-System Structure

A system as large and complex as a modern operating system must be

engineered carefully if it is to function properly and be modified easily. A

common approach is to partition the task into small components, or modules,

rather than have one monolithic system. Each of these modules should be

a well-defined portion of the system, with carefully defined inputs, outputs,

and functions. We have already discussed briefly in Chapter 1 the common

components of operating systems. In this section, we discuss how these

components are interconnected and melded into a kernel.

Simple Structure

Many operating systems do not have well-defined structures. Frequently, such

systems started as small, simple, and limited systems and then grew beyond

their original scope. MS-DOS is an example of such a system. It was originally

designed and implemented by a few people who had no idea that it would

become so popular. It was written to provide the most functionality in the

least space, so it was not carefully divided into modules. Figure 2.11 shows its

structure.

In MS-DOS, the interfaces and levels of functionality are not well separated.

For instance, application programs are able to access the basic I/O routines

to write directly to the display and disk drives. Such freedom leaves MS-DOS

vulnerable to errant (or malicious) programs, causing entire system crashes

when user programs fail. Of course, MS-DOS was also limited by the hardware

of its era. Because the Intel 8088 for which it was written provides no dual

mode and no hardware protection, the designers of MS-DOS had no choice but

to leave the base hardware accessible.

Another example of limited structuring is the original UNIX operating

system. Like MS-DOS, UNIX initially was limited by hardware functionality. It

consists of two separable parts: the kernel and the system programs.

The kernel is further separated into a series of interfaces and device drivers, which have

been added and expanded over the years as UNIX has evolved. We can view the

traditional UNIX operating system as being layered to some extent, as shown in

Figure 2.12. Everything below the system-call interface and above the physical

hardware is the kernel. The kernel provides the file system, CPU scheduling,

memory management, and other operating-system functions through system

calls. Taken in sum, that is an enormous amount of functionality to be combined

into one level. This monolithic structure was difficult to implement and

maintain. It had a distinct performance advantage, however: there is very little

overhead in the system call interface or in communication within the kernel.

We still see evidence of this simple, monolithic structure in the UNIX, Linux,

and Windows operating systems.

Please talk about this discussion in your own words.

Discussion # 7

“Virtual Machines,” of Operating System Concepts

Type 1 Hypervisor

Type 1 hypervisors are commonly found in company data centers and are in a

sense becoming “the data-center operating system.” They are special-purpose

operating systems that run natively on the hardware, but rather than providing

system calls and other interfaces for running programs, they create, run, and

manage guest operating systems. In addition to running on standard hardware,

they can run on type 0 hypervisors, but not on other type 1 hypervisors.

Whatever the platform, guests generally do not know they are running on

anything but the native hardware.

Type 1 hypervisors run in kernel mode, taking advantage of hardware

protection. Where the host CPU allows, they use multiple modes to give guest

operating systems their own control and improved performance. They implement

device drivers for the hardware they run on, because no other component

could do so. Because they are operating systems, they must also provide

CPU scheduling, memory management, I/O management, protection, and even

security. Frequently, they provide APIs, but those APIs support applications in

guests or external applications that supply features like backups, monitoring,

and security. Many type 1 hypervisors are closed-source commercial offerings,

such as VMware ESX while some are open source or hybrids of open and closed

source, such as Citrix XenServer and its open Xen counterpart.

By using type 1 hypervisors, data-center managers can control and manage

the operating systems and applications in new and sophisticated ways. An

important benefit is the ability to consolidate more operating systems and

applications onto fewer systems. For example, rather than having ten systems

running at 10 percent utilization each, a data center might have one server

manage the entire load. If utilization increases, guests and their applications can

be moved to less-loaded systems live, without interruption of service. Using

snapshots and cloning, the system can save the states of guests and duplicate

those states—a much easier task than restoring from backups or installing

manually or via scripts and tools.

The price of this increased manageability is the cost of the VMM (if it is a commercial product), the need to learn new management tools and methods, and the increased complexity.

Another type of type 1 hypervisor includes various general-purpose

operating systems with VMM functionality. In this instance, an operating system

such as RedHat Enterprise Linux, Windows, or Oracle Solaris performs its

normal duties as well as providing a VMM allowing other operating systems

to run as guests. Because of their extra duties, these hypervisors typically

provide fewer virtualization features than other type 1 hypervisors. In many

ways, they treat a guest operating system as just another process, albeit with

special handling provided when the guest tries to execute special instructions.

Please talk about this discussion in your own words.

Discussion # 8

“Distributed System Structures,” of Operating System Concepts

Communication Structure

Now that we have discussed the physical aspects of networking, we turn to

the internal workings. The designer of a communication network must address

five basic issues:

• Naming and name resolution. How do two processes locate each other to

communicate?

• Routing strategies. How are messages sent through the network?

• Packet strategies. Are packets sent individually or as a sequence?

• Connection strategies. How do two processes send a sequence of messages?

In the following sections, we elaborate on each of these issues.

17.4.1 Naming and Name Resolution

The first issue in network communication involves the naming of the systems

in the network. For a process at site A to exchange information with a process

at site B, each must be able to specify the other. Within a computer system,

each process has a process identifier, and messages may be addressed with the

process identifier. Because networked systems share no memory, however, a

host within the system initially has no knowledge about the processes on other

hosts.

To solve this problem, processes on remote systems are generally identified

by the pair <host name, identifier>, where host name is a name unique within

the network and identifier is a process identifier or other unique number within

that host. A host name is usually an alphanumeric identifier, rather than a

number, to make it easier for users to specify. For instance, site A might have

hosts named homer, marge, bart, and lisa. Bart is certainly easier to remember

than is 12814831100.

Names are convenient for humans to use, but computers prefer numbers for

speed and simplicity. For this reason, there must be a mechanism to resolve the

hostname into a host-id that describes the destination system to the networking

hardware. This mechanism is similar to the name-to-address binding that

occurs during program compilation, linking, loading, and execution (Chapter

8). In the case of host names, two possibilities exist. First, every host may have a

data file containing the names and addresses of all the other hosts reachable on

the network (similar to binding at compile time). The problem with this model

is that adding or removing a host from the network requires updating the data

files on all the hosts. The alternative is to distribute the information among

systems on the network. The network must then use a protocol to distribute

and retrieve the information. This scheme is like execution-time binding. The

first method was the one originally used on the Internet. As the Internet grew,

however, it became untenable. The second method, the domain-name system

(DNS), is the one now in use.

DNS specifies the naming structure of the hosts, as well as name-to-address

resolution. Hosts on the Internet are logically addressed with multipart names

known as IP addresses. The parts of an IP address progress from the most

specific to the most general, with periods separating the fields. For instance,

bob.cs.brown.edu refers to host bob in the Department of Computer Science at

Brown University within the top-level domain edu. (Other top-level domains

include com for commercial sites and org for organizations, as well as a domain

for each country connected to the network, for systems specified by country

rather than organization type.) Generally, the system resolves addresses by

examining the host-name components in reverse order. Each component has a

name server—simply a process on a system—that accepts a name and returns

the address of the name server responsible for that name. As the final step, the

name server for the host in question is contacted, and a host-id is returned.

For example, a request made by a process on system A to communicate with

bob.cs.brown.edu would result in the following steps:

1. The system library or the kernel on system A issues a request to the name

server for the edu domain, asking for the address of the name server for

brown.edu. The name server for the edu domain must be at a known

address, so that it can be queried.

2. The edu name server returns the address of the host on which the

brown.edu name server resides.

3. System A then queries the name server at this address and asks about

cs.brown.edu.

4. An address is returned. Now, finally, a request to that address for

bob.cs.brown.edu returns an Internet address host-id for that host (for

example, 128.148.31.100).

This protocol may seem inefficient, but individual hosts cache the IP addresses

they have already resolved to speed the process. (Of course, the contents of

these caches must be refreshed over time in case the name server is moved

or its address changes.) In fact, the protocol is so important that it has been

optimized many times and has had many safeguards added. Consider what

would happen if the primary edu name server crashed. It is possible that

no edu hosts would be able to have their addresses resolved, making them

all unreachable! The solution is to use secondary, backup name servers that

duplicate the contents of the primary servers.

Before the domain-name service was introduced, all hosts on the Internet

needed to have copies of a file that contained the names and addresses of each

host on the network. All changes to this file had to be registered at one site (host

SRI-NIC), and periodically all hosts had to copy the updated file from SRI-NIC

to be able to contact new systems or find hosts whose addresses had changed.

Under the domain-name service, each name-server site is responsible for

updating the host information for that domain. For instance, any host changes

at Brown University are the responsibility of the name server for brown.edu and

need not be reported anywhere else. DNS lookups will automatically retrieve

the updated information because they will contact brown.edu directly. Domains

may contain autonomous subdomains to further distribute the responsibility

for host-name and host-id changes.

Please talk about this discussion in your own words.