Ucla Cs111 Operating Systems (Spring 2003, Section 1) Introduction and History
Ucla Cs111 Operating Systems (Spring 2003, Section 1) Introduction and History
In some sense, the operating system is just a solution to a software engineering problem:
how do you hide the complexity and limitations of hardware from application
programmers?
The design of each operating system component begins with the following two questions:
1. What is the hardware interface? (the physical reality)
A track
Disk platters
Disk arm
Accessing a raw disk involves specifying the data, the length of data, the disk drive, the
track location(s), and the sector location(s) within the corresponding track(s).
write(block, len, device, track, sector);
However, at the application level, a programmer may prefer to specify a file and the
location of updates, without worrying about the underlying physical complexity of the
disk.
lseek(file, file_size, SEEK_SET);
write(file, text, len);
Coordination
A simple example of coordination is protection. An operating system needs to protect
different applications from crashing each other and crashing the operating system.
Preventing applications from crashing each other is mainly achieved by making instances
of applications run in different address spaces. Literally, an address space defines all
memory address that an instance of application can touch.
Preventing applications from crashing the operating system is commonly achieved by
having dual-mode operations. When the operating system is running (e.g., the CPU is
running under the kernel-mode), anything goes. When an application is running (e.g., the
CPU is running under the user-mode), an application can only access states within its
own address space.
Note that if the operating system is dedicated to a single application, dual-mode
operations are not required.
2000
1000 MIPS
2 ns
2 ms
56 Kbits/second
128 Mbytes
6 Gbytes
<= $1
64
<=1
Factor
1000
250
9
200
2000
6000
100000
8
.01