CS444 Sept 6--first class

Tues., Sept. 5--first class: Intro, System Calls, Virtual Machine concept

Goals—

traditional OS coverage
Specifically, how the OS implements system security
UNIX/Windows NT/2000/XP (Win32 API) as similar programming environments
C programming—advanced points, conventions, differences from Java
full understanding of the x86 architecture needed for the minimal OS we will be developing (serial ports, timer, interrupts)

First topic: What is an OS?

Ref: Tanenbaum, p. 2, simplified pic:

-----------
apps <-- CPU running in user mode (includes compilers, shells, etc.)
-----------
OS <-- CPU running in kernel mode
-----------
hardware
-----------

The OS provides apps with a virtual machine and itself is a program working with the actual hardware.

The virtual machine is the OS-provided program execution environment, for example, what you have already been using for your C programs in CS310. The actual hardware was covered in CS241, so you have some background on the two sides.

What about the Java “virtual machine”? It is a virtual machine in the same sense, that is, it provides an execution environment for programs, in this case just Java programs. The Java VM sits on top of the OS VM, so there is another layer in the picture for Java programs. C programs run right on the OS, with the help of the C library. (You could draw a layer for the C library, but the C/C-lib layer boundary wouldn’t be as strong a division as the others.)

We will concentrate on the C programming environment, since it is so close to the OS.

UNIX/Win32 virtual machine (app execution environment)

timesharing: each app uses CPU as if it owns it
private “flat” memory (virtual memory, also “VM”)
stack that grows automatically when items are pushed on it
{system calls} The “system API” These are called as functions by the apps to do i/o, get time, etc.

Note: Win32 (or WinAPI, a synonym) is actually the name of the system API for Windows NT/2000/XP, and this API is also provided on Windows 98/Me, but these last two do not have all the infrastructure of a modern OS. On the high end, Win32/WinAPI includes 64-bit address support, which is sometimes called, to try to make it clear, "Win32 for 64-bit Windows." We will only be studying the full-fledged modern OS’s, so “Win32” will mean NT/2000/XP, with 32 or 64-bit addresses, as opposed to UNIX/Linux, grouped as “UNIX”, since Linux is truly a kind of UNIX. UNIX also supports 32 or 64 bit addresses. For discussion of Win32/WinAPI terminology, see http://en.wikipedia.org/wiki/Win32.

In our department, we have many Solaris UNIX machines and a smaller number of Linux and Windows XP machines. The homework will be done on the Solaris system “ulab”, also known as u17.cs.umb.edu. All the “blades”, blade01.cs.umb.edu, blade02, …, blade64, are also running Solaris.

User Memory Layout (details for Solaris UNIX):

                 code      data         C lib DLL stack
                 ---       ---            ----    <----
        |--------|--------|------------ … -------------------|

Address 0 0x10000 0x20000 0xffffffff

0xf = 1111 binary, so 4 binary 1’s for each f. 0xffffffff has 8 f’s, so has 32 bits of 1s.

0xffffffff: 32 bits of 1s, highest possible 32-bit address This is a 32-bit user address space. The … part could be used by a larger user program.

Important powers of 2: 1G = 2³⁰, 1M = 2²⁰, 1K = 2¹⁰

So 0xffffffff = 2³² - 1 = 4G -1. Thus the Solaris user address space is 4 G bytes in size, the full 32-bit address space size.

There can be holes in the available memory for a program, stretches of addresses that cause segmentation faults when referenced. We still call the memory "flat," because one sequence of memory addresses still can describe the whole thing, and every byte of usable memory has its own unique address.

In a non-flat memory, various pieces, usually called segments, are only separately usable. In UNIX or Windows, we can malloc 10 MB of memory (say) at a time and if it succeeds, we are guaranteed one stretch of addresses covering 10 MB of memory.

The OS code, the kernel, is not in this space but off somewhere else—shown in a cloud on the board. The system call causes execution to jump right out of this user space into the kernel. In the kernel, the system call implementation code executes to do the service, and then returns to the next user instruction after the system call instruction.

The Solaris user address space is 4 G bytes in size. Other UNIX implementations provide 3-4G. Linux provides 3G. Windows 2000 provides 2G by default, 3G by special boot command for Advanced Servers. The size of the user memory space (above 1G) is only relevant for the largest apps, notably huge database systems.

DLL: dynamic-link library, or just dynamic library in UNIX parlance, code that can be called by a program but is not stored in the program’s executable file, Instead, it is brought into user memory at runtime. Functions are located in the DLL via “dynamic linkage” at runtime. Once this linkage is done, calls are direct, since the DLL is in user memory.

User Memory Layout for Solaris UNIX: 4G user address space (the first 0x10000 bytes are purposely made unavailable to trap null pointer accesses)

                 code      data              C lib DLL    stack
                 ---       ---                -----      <----
        |--------|--------|------------ … -------------------|

Address 0 0x10000 0x20000 0xffffffff

User Memory Layout for Win32: 2G user address space

code data C lib DLL stack

--- --- ----- <----

|--------|--------|------------ … -------------------|

Address 0 0x7fffffff