OS/2 Warp

CS-450-01: Operating Systems

Fall 2003

Chris Algire

Jon Depner

Jason Shifflet

Daniel Kvitko

Ryan Slominski

Contents

Introduction

Processor

Threads

Memory Management

Memory Data Structures

File Management

File Data Structures

Scheduling

Deadlock

Synchronization

Conclusion

Bibliography

Introduction

OS/2 was a revolutionary operating system when it was introduced. It was the first PC OS to break the 640 KB memory barrier, and among the first ones to support 32-bit CPUs such as Intel i386 when it was announced in 1985. Therefore, it became the first 32-bit PC OS, with full support for Intel’s i386 processor when it was released in 1991(Both, URL). Designed with the server environment in mind, it was also the first OS to support multi-tasking support as well as to provide dynamic linking calls to an API through the REXX scripting language (Necasek, URL).

In collaboration with Microsoft, OS/2 was a successful operating system and it matured until Microsoft and IBM separated in the project. Back in 1981, IBM needed an operating system for the IBM PC/AT. Microsoft, which already had an OS to fill the IBM product line, agreed with IBM to produce and OS for IBM PCs, and for $20,000, Gates was granted modification to the DOS OS provided by IBM(Both, URL). IBM severed its relationship with Microsoft as it demanded the software manufacturer to include features to the OS, which Microsoft hesitated to comply with. These features included multitasking and support for Intel’s i286 CPU. Microsoft’s “Windows” operating system eventually proved OS/2 to be antediluvian in that although it had a consistent user interface; it lacked the ease of use provided by Windows. Installing a printer, for example, was accomplished in two steps with Windows 3.0 while it took multiple steps to install a printer in OS/2. Microsoft’s success with Windows 3.0 prompted Microsoft to abandon its alliance with IBM; IBM was left to do the project alone, and by 1987, IBM was able to introduce the first PC OS to support multitasking (based on hardware support)(Both, URL). However, OS/2’s demise was furthered by IBM and Microsoft’s contracts in the project, which lasted even after Microsoft released its Windows operating system. IBM was forced to construct OS/2 such that it should work with Windows, and not as a stand-alone product. Although IBM dramatically reduced the price of OS/2, most users preferred the interface provided by Windows. However, OS/2 continued to be in use by major corporations due to the operating system’s stability, and continued additions to the state-of-the-art. Since 1987, OS/2 acquired features such as support for FAT drives, as well as HPFS file system. By 1989, the OS advanced to be able to run on multiple platforms from Motorola, Sun and DEC (Both, URL). OS/2 has since evolved to become OS/2 Warp 2 in the early 90’s to OS/2 Warp 4 today. It has since acquired a graphical user interface and strong Windows compatibility (No Author, URL).

Processor

OS/2 Warp runs on the Intel architecture and supports both uniprocessing and symmetric multiprocessing (SMP). The Intel architecture offers four privilege modes, or protection rings, numbered 0-3, with zero having the highest privilege (Gollmann, 1999). OS/2 makes use of rings 0, 2, and 3.

Ring 0 is the kernel or supervisor mode. OS/2 implements the kernel and physical device drivers here. In this mode, processes have full access to the entire system and all of its resources; therefore, the operating system must be very particular with which processes may operate in kernel mode. Only certain, highly trusted processes are permitted to operate in ring 0.

Ring 2 can be considered a restrictive supervisor mode. OS/2 implements some parts of the Presentation Manager (which handles drawing to output devices) and 16-bit DLLs here. Processes in Ring 2 are granted limited direct access to hardware.

Ring 3 is the application, or user mode. This is where OS/2 runs user applications. In this mode, each process is highly protected from other processes of the same level. In addition, ring 3 processes do not have direct hardware access. All access must be made through established interfaces (APIs), which allow transition to a more privileged ring to handle hardware access requests (Warpstock, 2000).

Threads

Threads are a unit of execution; each process is made up of at least one thread. The OS/2 can have a maximum of 4095 threads for the whole system. (Sullivan, 1996) Thread management is critical, therefore the OS/2 implements many control structures such as pipes, queues, semaphores, and critical sections to decrease the chances of deadlock. Every thread has a process control block which the OS/2 uses to maintain the progress as well as the priority. Threads not only have a priority, but a state. The states of a thread include: running, blocked, or frozen. The threads state as well as it priority determines if that process will be serviced by the CPU. The OS/2 warp has a one-to-one relationship between user and kernel level threads. The kernel holds the information for each process and thread. The OS/2 provides system calls to create and manage threads.

Memory Management

There are three key features to OS/2 Warp memory management. First, it protects processes from harming one another by reading or writing to unauthorized parts of memory. Second, it allows processes more memory than physically present in the system. Finally, it allows processes to share memory if desired.

OS/2 Warp features a 32-bit flat memory model with memory blocks of any size up to 512 MB per process. Previous versions of OS/2 used a 16-bit segmented memory model with fixed size memory blocks of 64K bytes per process. Many personal computers do not have 512 MB of main memory but can still take advantage of the full 512 MB per process because OS/2 Warp features virtual memory. Virtual memory takes advantage of the fact that only the process currently executing needs to be in main memory. Swapping is the act of moving blocks of memory from the hard disk to main memory and vice versa and is the mechanism which allows OS/2 Warp to implement virtual memory. Virtual memory is limited by the amount of hard disk space in the swap file and ultimately the amount of space on the swap drive. Swapping is totally transparent to processes so OS/2 programmers need not worry about where their program’s memory is. They are able to treat their assigned memory as a contiguous chunk that is always in memory even thought it actually may not be contiguous or in memory in whole or in part. OS/2 Warp uses a type of swapping called paging. Paging differs from swapping in that the size of a block of memory is fixed instead of variable. OS/2 Warp pages are 4K. The advantage of having fixed size memory blocks is that there are never holes in memory which cannot be filled (Reich, 1995).

Memory Data Structures

OS/2 Warp is designed for 32-bit applications but is backwards compatible with 16-bit applications which complicates memory management. There are four main data structures in 16-bit memory management. Two are descriptor tables; one is the Global Descriptor Table (GDT) and the other is the Local Descriptor Table (LDT). The system has a single GDT and each process has its own LDT. Descriptor tables contain Descriptors which specify the physical address of a segment of memory along with whether the segment is currently physically in memory, and the privilege level required to access that segment. The other data structure is the Selector. The Selector contains an offset into a descriptor table, either the LDT or GDT. It also contains an indicator of which descriptor table it points to and an indicator of the privilege level of the process which is currently assigned the Selector. When segments of memory are swapped in or out of memory the memory manager simply modifies the necessary Descriptors. Selectors are never modified while a process is assigned to it thereby creating the illusion that the processes memory is always in physical memory (Reich, 1995).

Figure 1. 32-bit Memory Data Structures.

There are three main data structures in 32-bit memory management. They are the Page Table Directory (PTD), the Page Table (PT), and the Page Frame (PF). A PTD contains pointers to Page Tables. Page Tables contain Page Frames. In 32-bit memory management bits 22 to 31 specify an offset in the PTD. Bits 12 to 21 specify an offset in the page table. In other words, bits 12 to 21 indicate a page frame in a page table. Bits 0 to 11 specify the actual byte being referenced in the page. A page frame contains the physical address of a page, which may be incorrect if the page is not currently in memory. It also contains indicators of whether the page is read/write, present in memory, and whether it has been accessed. To allow both 16-bit and 32-bit operation the Descriptor in the 16-bit memory scheme actually has a 32-bit address instead of a 16-bit one. 16-bit addresses go through the normal 16-bit translation and then the 32-bit translation (Reich, 1995).

File Management

While providing support for many different file systems, OS/2 Warp prefers IBM’s proprietary High Performance File System (HPFS), which implements the operating system’s native file management functions.

HPFS provides all the standard file management functions such as opening/closing, creating/deleting, and reading/writing files and directories, as well as providing some file security and other functions via various file attributes.

In OS/2’s infancy, it used the FAT file system, but it did not take long for IBM to realize the limitations and shortcomings of the inefficient FAT file system, which led to the development of HPFS.

The HPFS file system was first introduced with OS/2 1.2 to allow for greater access to the larger hard drives that were then appearing on the market. Also, IBM saw a need to extend filename length, organization, and security for the demands of networked computing. HPFS uses the directory organization of FAT, but added automatic sorting of the directories based on filenames. Filename length was extended to up to 254 characters. HPFS also allowed a file to be composed of "data" and special attributes to support other naming conventions and security. In addition, allocation units were changed from clusters to physical sectors, reducing lost disk space (OS/2 Webmasters, 1996).

HPFS handles directories differently than FAT. Under HPFS, a directory holds what is known as the attribute file, which includes information about the modification, creation, and access dates and times. Also, instead of pointing to the first cluster of the file, as does FAT, the directory entries under HPFS point to the Fnode. The Fnode can contain the file's data, or pointers that may point to the file's data or to other structures that will eventually point to the file's data (Frommert). Fnodes are discussed further in the file data structures section.

OS/2 Warp’s High Performance File System clearly offers some advantageous features concerning its file management options and performance capabilities. The following section on file data structures discusses some of the file structures HPFS implements.

File Data Structures

OS/2 Warp implements its native file system through various data structures including Fnodes, sector runs, B+ trees, and B- trees, each which plays an important role in the high performance of HPFS.

Every file or directory is fixed on a structure called an Fnode. The Fnode is the first sector allocated to a file or directory. Each Fnode contains control and access history information, extended attributes, access control lists, the file length, the first 15 characters of the file or directory name, and an allocation structure, which defines the size and location of the file’s storage through a collection of sections of contiguous bytes, called sector runs (Frommert).

Relatively small or highly contiguous files can be described completely within an Fnode. An Fnode is able to define a file of up to eight runs, with each run consisting of up to 16MB for a maximum file size of 128MB, see figure 1.

However, when files are larger than 128MB or very fragmented, and end up consisting of more than eight runs, the Fnode contains the roots for a B+ tree of allocation sectors which then contain pointers to the file’s sector runs. The result is an Fnode allocation structure pointing to a maximum of twelve B+ trees, which in turn, may each point to up to forty runs, drastically increasing the file size to a theoretical maximum size of 7.68GB (12*40*16MB), see figure 3. If for some reason this two level tree is not sufficient to define a file, the file system may use intermediate levels, each holding up to sixty nodes, which increases the maximum file size to an amazingly large number. Using this data structure, translating a logical file offset to a sector number is extremely fast. The file system just needs to traverse the list or B+ tree of lists until it locates the correct run and then performs a simple calculation to identify the desired sector. This “run” system also makes logically extending a file trivial when a newly assigned sector is contiguous with the file’s previous last sector; the file system simply needs to increment the file’s last sector run pointer and mark the sector’s use bit (Frommert).

Although directories logically have a different meaning than files, the file system treats directories similarly to files and their implementation requires similar structures. Directories are also fixed to Fnodes. A pointer to the Fnode for the root directory resides in the Super Block, which is a structure located in logical sector 16 on the volume. The Fnodes for all other directories are contained in subdirectory entries in the respective parent directories. Directories can grow to any size. They are built from 2KB directory blocks with each block containing one to many directory entries. These directory entries contain time and date stamps, an Fnode pointer, a usage count, the length of the directory name, the name itself, and a B-Tree pointer. When a directory becomes too large to be stored in one directory block, additional blocks are allocated in a B- tree arrangement. The entries in a directory block are sorted in alphabetical order, with a dummy entry marking the end of the block. This automatic sorting makes searching for a specific name very fast and efficient, even when searching a large B- tree (Microsoft, 2002; Frommert).

OS/2 Warp’s file data structures including Fnodes, sector runs, B+ trees, and B- trees allow for quick, efficient implementations of operations on files and directories, providing a vast improvement in file system performance over the originally used FAT file system.

Scheduling

The corner stone of a multiprocessing operating system is the scheduling. Scheduling insures that every process has a chance to perform its task on the CPU. The OS/2 uses a preemptive-priority scheduler to handle its multiprocessing ability. The priorities of the OS/2 are broken down into four categories starting with the highest priority which are Time Critical, Server class, Regular class, and the Idle class (Reich, 1995). Each of this priority categories are in turn broken down into 31 different priority queues. A promotion process is implemented as needed to insure that starvation is kept to a minimum. The promotion of a process occurs after a process has waited in the ready queue for three seconds and has not been given a chance to be serviced by the CPU. In the config.sys file, the command Maxwait = n (n being some amount of time in seconds) can be used to increase or decrease the wait for promotion (Halliday, 1989).

Maxwait is but one example of how the scheduler can be manipulated. Using default settings, the scheduler will check to see if there are any other processes of higher priority every time a new process enters the ready queue. The OS/2 has a minimum and a maximum amount of time that a process will stay on the CPU, A process will run uninterrupted for at lest 32 milliseconds. If there is no process of higher priority in the ready queue then the process will run for 248 milliseconds before the scheduler will force the process to give up the CPU. In order to customize scheduling further, to meet individual processing needs, the Timeslice command can be used. Timeslice = x, y (x and y in milliseconds) can be used to change the smallest amount of time the process can have the CPU, regardless of other higher priority processes, and the maximum amount of time the process can have until it is forced to give up the CPU, respectively (Halliday, 1989). The OS/2 scheduler is dynamic in and of it self, when more than one time critical thread is in the ready queue the Timeslice changes to eight milliseconds. The Timeslice command has no effect in this situation. In general the Timeslice option allows for flexibility in scheduling enabling the user to maximize the amount of work done by the CPU, by customizing it for the processes that will run on that machine. In order to make informed decisions about modifications to the default settings of the scheduler, the OS/2 provides commands such as PSTAT. (Stevens, ?) PSTAT, entered at the command prompt, allows the users to get information about the processes that are utilizing the CPU. Information such as, which process and how long they are utilizing the CPU.

Deadlock

Deadlocks in OS/2 are handled by a multitude of mechanisms: Deadlock prevention, deadlock avoidance, and through the implementation of the round-robin schedulingalgorithm as well as the use of semaphores. A combination of these mechanisms ensures that deadlocks are minimized, and the system is discouraged from entering a deadlocked state.