WHAT IS AN OPERATING SYSTEM?
I think its hard to pin down what an operating system is other than saying it is the
software that runs in kernel mode and even that is not always true. Basically operating systems perform two unrelated functions: providing
application programmers a clean
abstract set of resources instead of the messy hardware ones and managing these
hardware resources.
Therefore,
OPERATING SYSTEM = EXTENDED MACHINE + RESOURCE MANAGER
Depending on who is doing the talking, you might hear
mostly about one function or the other.
But here we will now look at both.
First case: Extended Machine
The architecture (instruction set, memory organization, I/O, and bus structure)
of most computers at the machine language level is primitive and awkward
to program, especially for input/output. To make this point more concrete, consider
how floppy disk I/O is done using the NEC PD765 compatible controller
chips used on most Intel-based personal computers. We use the
floppy disk as an example, because, although it is obsolete, it is much simpler
than a modem hard disk.
[ The PD765 has 16 commands, each specified by loading
between 1 and 9 bytes into a device register. These commands are for reading and
writing data, moving the disk arm, and formatting tracks, as well as initializing,
sensing, resetting, and recalibrating the controller and the drives.
The most basic commands are read and write, each of which requires 13 parameters,
packed into 9 bytes. These parameters specify such items as the address
of the disk block to be read, the number of sectors per track, the recording mode
used on the physical medium, the intersector gap spacing, and what to do with a
deleted-data-address-mark. When the operation is completed,
the controller chip returns 23 status and error fields packed into 7 bytes.
As if this were not enough, the floppy disk programmer must also be constantly
aware of whether the motor is on or off. If the motor is off, it must be turned on
(with a long startup delay) before data can be read or written. The motor cannot
be left on too long, however, or the floppy disk will wear out.]
If you do not understand this mumbo jumbo, do not
worry; that is precisely the point-it is rather esoteric. The programmer is
thus forced to deal with the trade-off between long startup delays versus wearing
out floppy disks (and losing the data on them).
Without going into the real details, it should be clear that the average programmer
probably does not want to get too intimately involved with the programming
of floppy disks (or hard disks, which are worse). Instead,
what the programmer
wants is a simple, high-level abstraction to deal with.
In the case of
disks, a typical abstraction would be that the disk contains a collection of named
files. Each file can be opened for reading or writing, then read or written, and finally
closed. Details such as whether or not recording should use modified frequency
modulation and what the current state of the motor is should not appear in
the abstraction presented to the application programmer.
Abstraction is the key to managing complexity. Good abstractions turn a
nearly impossible task into two manageable ones. The first one of these is defining
and implementing the abstractions. The second one is using these abstractions
to solve the problem at hand.
One abstraction that almost every computer user
understands is the file. It is a useful piece of information, such as a digital photo,
saved e-mail message, or Web page. Dealing with photos, e-mails, and Web pages
is easier than the details of disks, such as the floppy disk described above. The job
of the operating system is to create good abstractions and then implement and
manage the abstract objects thus created. Abstractions are one of the keys to understanding operating systems.
This point is so important that it is worth repeating in different words. Real processors, memories, disks, and other devices are very complicated
and present difficult, awkward, idiosyncratic, and inconsistent interfaces to the
people who have to write software to use them. Sometimes this is due to the need
for backward compatibility with older hardware, sometimes due to a desire to
save money, but sometimes the hardware designers do not realize (or care) how
much trouble they are causing for the software. One of the major tasks of the operating
system is to hide the hardware and present programs with nice, clean, elegant, consistent, abstractions to work with instead.
Operating systems turn the ugly into the beautiful using abstraction concept.
It should be noted that the operating system's real customers are the application
programs (via the application programmers, of course). They are the ones
who deal directly with the operating system and its abstractions. In contrast, end
users deal with the abstractions provided by the user interface, either a commandline
shell or a graphical interface. While the abstractions at the user interface may
be similar to the ones provided by the operating system, this is not always the
case. To make this point clearer, consider the normal Windows desktop and the
line-oriented command prompt. Both are programs running on the Windows operating
system and use the abstractions Windows provides, but they offer very different
user interfaces. Similarly, a Linux user running Gnome or KDE sees a very
different interface than a Linux user working directly on top of the underlying
(text-oriented) X Window System, but the underlying operating system abstractions
are the same in both cases.That is a large and important
subject, but one only peripherally related to operating systems.
Second case: Resource Manager
Modern computers consist of processors, memories, timers, disks, mice, network interfaces, printers, and a wide variety of other devices. The concept of an operating system as primarily providing abstractions to application
programs is a top-down view. An alternative, bottom-up, view holds
that the operating system is there to manage all the pieces of a complex system.
In the alternative view,
the job of the operating system is to provide for an orderly and controlled allocation
of the processors, memories, and I/0 devices among the various programs
competing for them.
Modem operating systems allow multiple programs to run at the same time.
Imagine what would happen if three programs running on some computer all tried
to print their output simultaneously on the same printer. The first few lines of
printout might be from program 1, the next few from program 2, then some from
program 3, and so forth. The result would be chaos. The operating system can
bring order to the potential chaos by buffering all the output destined for the printer
on the disk. When one program is finished, the operating system can then copy
its output from the disk file where it has been stored for the printer, while at the
same time the other program can continue generating more output, oblivious to
the fact that the output is not really going to the printer (yet).
When a computer (or network) has multiple users, the need for managing and
protecting the memory, 110 devices, and other resources is even greater, since the
users might otherwise interfere with one another. In addition, users often need to
share not only hardware, but information (files, databases, etc.) as well.
In short,
this view of the operating system holds that its primary task is to keep track of
which programs are using which resource, to grant resource requests, to account
for usage, and to mediate conflicting requests from different programs and users.
Resource management includes multiplexing (sharing) resources in two different
ways:
in time and in space. When a resource is time multiplexed, different
programs or users take turns using it. First one of them gets to use the resource,
then another, and so on. For example, with only one CPU and multiple programs
that want to run on it, the operating system first allocates the CPU to one program,
then, after it has run long enough, another one gets to use the CPU, then another,
and then eventually the first one again. Determining how the resource is time multiplexed-
who goes next and for how long-is the task of the operating system.
Another example of time multiplexing is sharing the printer. When multiple print
jobs are queued up for printing on a single printer, a decision has to be made
about which one is to be printed next.
Problem with large input (e.g., 32 bits)
Posts
