For purposes of this book, we'll consider an operating system to be the supporting software structure on which application programs run.
This support structure includes the facilities to manage the computer system's resources and any utility programs needed to maintain and configure the operating system.
The heart of system administration is configuring an operating system to create an environment suitable for the applications that the users require.
One can classify operating systems into two broad groups, early and modern, based on an analysis of three key features:
- Ability to share CPU resources between multiple programs.
- Methods employed to control access to system storage.
- Methods employed to protect system and application memory from corruption.
Early operating systems provided poor support for these three features.
Running multiple programs, while possible, was done via a cooperative system which depended on each application program to release the CPU periodically to allow its peer processes to run.
Protection of system storage was limited. Critical system files and user files were not protected from damage by user-level applications.
Finally, early operating systems did not provide memory protection for individual processes or the operating system kernel, thus allowing application “bugs” to result in damage to the parts of the operating system and applications loaded into memory.
The poor reliability of early operating systems is (in part) due to the lack of support for these features.
Modern operating systems are those which provide good support for these three features.
All of the UNIX variants, Linux, Mac OS X and Windows NT, 2000 and XP provide support for these features.
As a result, these modern operating systems are more robust and reliable.
At an abstract level, modern operating systems share several design concepts. Due to the size and complexity of modern operating systems, each consists of a layered design. A core part of the operating system forms the base of the design and directly interacts with the computer hardware. The core layer is usually loaded into memory when the computer boots and stays there throughout. A middle layer (or layers), made up of a suite of libraries and services, form an abstraction of the computer hardware and provide a connection to the core layer. Items in the middle layer may be loaded as needed. Riding on top of these middle layers comes the user shell (or Graphical User Interface - GUI) and the application programs themselves. The layers are protected from each other and connected to each other through specific Application Programming Interfaces (API's). This provides modularity, allowing individual components in a layer to be changed without effecting items in another layer. It also provides a framework for reliability and security through careful control of the interactions between layers.
UNIX systems refer to the Operating System’s core component as the kernel.
A UNIX kernel handles the interaction with the system hardware.
The UNIX kernel is specific to a particular computer or group of computers that share a common hardware design.
UNIX kernels are built around one of two designs:
- a single, monolithic kernel or
- a micro-kernel.
The monolithic design is older and uses a single binary image to provide the resource management and hardware interface functions of the core layer. Some examples of the monolithic design are Linux and Solaris.
A micro-kernel design uses a very small task management component and a suite of modules for all other resource management functions. Windows NT, Windows 2000, Windows XP and Mac OS X are examples of micro-kernel designs.
Modern monolithic kernels extend their designs by allowing additional components, known as loadable modules, to be added to the kernel after it starts running. These loadable modules are used to provide additional features such as the code needed to control less commonly used devices, or 3rd party software to control new devices. Since a loadable module functions as part of the kernel, care needs to be taken to assure that any module loaded into the kernel is secure. Systems requiring high security will need to disable the capability of loading modules and use a purely monolithic kernel to avoid the possibility of changes to the core functions of the operating system. Linux and Solaris are two examples of monolithic kernel designs that include loadable modules.
The recent incarnations of Windows; NT, 2000, and XP share a similar layered construction approach with UNIX.
These recent versions of Windows are based on a micro-kernel design using a small kernel layer and hardware abstraction layer at their base.
The middle layer is made up of dynamically loaded libraries and services.
The applications layer contains the familiar applications such as text processors, spreadsheet, web browsers, etc.
Note that the dynamically loaded libraries (DLLs) found in Windows differ significantly from the loadable kernel modules found in some UNIX variants. Loadable modules are specific to a given kernel and one generally cannot have multiple versions available at the same time. DLLs do allow for multiple versions often resulting in mismatched DLLs. These instances of incorrect versions for a DLL and a given operating system kernel or application program, is a common source of problems on Windows systems.
Hardware designs are often called hardware architectures.
Fine distinctions between hardware architectures matter most at the core level of the operating system.
Differences such as “Pentium III versus Intel 486” or “SPARC 4m versus SPARC 4c” are important in the selection of a kernel or operating system distribution.
On many vendor’s hardware this simple description is sufficient to make a choice of operating system.
On PC hardware, the hardware architecture is often only part of the information needed to select an operating system.
The variety of PC hardware (models of video, I/O, and network cards) all require specific software drivers.
The availability of drivers for a specific device and a specific operating system is critical.
All components in the PC, including each interface card and the motherboard, need to be supported by the operating system vendor
At the application layer level, the hardware architecture distinctions become less fine.
At this layer general categories such as "Intel x86" or "SPARC" are sufficient to describe whether a particular program binary will run on a particular machine.
This general hardware description is sometimes called the application architecture.
The application architecture is often stated more completely as a combination of the general hardware architecture and the operating system. You will frequently see application architectures described as Linux x86 or Solaris SPARC. Still more detailed specifications such as Linux x86 libc5 or Linux alpha 2.2.17 add the kernel version or libraries needed by the application to the description of the operating system and hardware architecture. The main purpose of these application architecture specifications is help match application binaries to the operating systems and hardware on which they will run.
No comments:
Post a Comment