Operating System Design

Hello readers!

We have discussed the importance of operating systems, and today, we dive into creating goals for designing operating systems and will see different aspects of Operating Systems.

Let's dive in.

When we design a system, we should first decide the goals, which become the basis of choices among various algorithms and strategies available to us.

The reason for going with this fundamental is because once we understand the goals, The directions to design would be more straightforward to implement.

The learning objective for this issue is to describe the services an operating system provides to users, processes, and other systems and explain how operating systems are installed and customized and how they boot.

Let's have a look at the Operating Systems from three different perspectives.

Operating System Services

We must remember that these services are provided to make the programming task more manageable.

Let's discuss the services by Operating Systems.

To ensure the services run smoothly for the User, there are some special services for the efficient functioning of the above services.

Operating System Interface

There are two fundamental ways for users to work with operating system interfaces.

Now, we know the services and ways to interact with operating systems. How does the user interface tell the services to do the tasks? What is the secret here?

Operating System Communication

The secret is System calls, which provide an interface for the User to communicate the tasks to the Operating System. These are the APIs available to application developers to interact with the Operating Systems. The APIs used in UNIX, Linux and Mac OS are called POSIX since all these are Portable Operating System Interface-based systems. It's a family of standards specified by IEEE for maintaining compatibility among operating systems.

System calls are categorized into five major groups:

1. Process control 

   • end, abort 
   • load, execute
   • create process, terminate process
   • get process attributes; set process attributes
   • wait for time
   • wait event, signal event
   • allocate and free memory 

2. File management

   • create a file, delete a file 
   • open, close
   • read, write, reposition
   • get file attributes, set file attributes 

3. Device management

   • request device, release device 
   • read, write, reposition
   • get device attributes, set device attributes
   • logically attach or detach devices 

4. Information Maintenance

   • get time or date, set time or date 
   • get system data, set system data
   • get process, file, or device attributes
   • set process, file, or device attributes 

5. Communications

   • create, delete communication connection 
   • send, receive messages
   • transfer status information
   • attach or detach remote devices

Operating System Design

So far, we have covered the different aspects of the Operating system and understood the services provided, interface available and communication in the Operating System. These are the goals to achieve when we design an Operating System. 

Now, we will first lay the goals in User and System Goals.

Of course, These specifications are not specifically valuable for System Design and may be interpreted differently. However, The wide range of existing systems shows that different requirements can result in many solutions.

Since this is a highly creative task, Let's look at some concepts with general principles.

Mechanisms and Policies

Mechanisms determine how to do something, and Policies decide what will be done. For instance, virtual memory serves as a technique to manage system memory resources efficiently, but determining the size of the virtual memory for a specific application is a matter of policy.

The separation of policy and mechanism is essential for flexibility. For instance, consider a mechanism for prioritizing specific programs over others and the mechanism is appropriately separated from the policy. In that case, it can be used either to support a policy decision that I/O-intensive programs should have priority over CPU-intensive ones or to support the opposite policy.

Policy decisions play a crucial role in the allocation of resources. A policy decision is required whenever there is a need to determine whether a resource should be allocated. When the decision involves the method of implementation rather than the choice of action, it's the mechanism that needs to be defined.

Implementation

After an operating system is designed, it must be implemented. Operating systems are:

• Collections of programs developed by different individuals over extended periods.
• Leading to implementations in various languages, from assembly to high-level languages like C and C++. Nowadays, Rust.

Modern systems, including Linux and Windows kernels, are mainly written in C, with assembly used for specific low-level tasks. The performance of an operating system is more influenced by the quality of its data structures and algorithms than by assembly language.

Advantages of High-Level Languages:

• Faster and more compact code development.
• Enhanced readability and more straightforward debugging.
• Improved maintainability and portability across different hardware platforms.

Operating System Structure

Although many design approaches exist, we will see OOP techniques in the LINUX case study to create a modular Kernel. The kernel comprises core components and dynamical links to additional services during boot or run time. This type of design is common in modern implementations of UNIX, such as Linux, Mac OS X, and Windows. In the LINUX case study, We will discuss in-depth how different components of an Operating System are interconnected and combined in a Kernel.

Operating System Generation

Operating systems are often designed to be versatile, supporting a range of machines. The System Generation (SYSGEN) process tailors the OS to a specific hardware configuration at a site, ensuring compatibility and optimal performance.

A unique SYSGEN program is used to configure the OS. This program may gather necessary hardware information through direct queries to the User, probing the hardware, or reading predefined configuration files. Key details include:

• CPU type and special features (e.g., extended instruction sets).
• Boot disk format, including partitioning details.
• Available memory is often determined by probing memory addresses.
• Peripheral devices available, including device numbers, types, models, and specific characteristics.
• The desired OS options and parameters include buffer sizes, scheduling algorithms, and process limits.

Operating System Boot

Now, the most exciting topic is System Boot. Once the operating system is configured, it must be accessible to the hardware. The question then arises: how does the hardware recognize the location of the kernel and the method to load it?

The loading of the kernel to start the operating system in a computer is called booting the system. Let's look at this multi-step process when we turn on our machine.

1. BIOS - The First Step

• The Basic Input/Output System (BIOS) initializes essential hardware components such as the screen and keyboard.
• BIOS conducts the Power On Self Test (POST) to check the main memory's functionality.
• BIOS firmware is stored on the motherboard's Read-Only Memory (ROM) chip.
• The operating system controls the subsequent boot process following the BIOS initialization and checks.

2. Master Boot Records (MBR) and Boot Loader

• After completing the Power On Self Test (POST), control shifts from the BIOS to the boot loader.
• The boot loader is typically found on the system's hard disk within the boot sector for BIOS/MBR-configured systems. Until this point, the system does not access any mass storage devices.
• Subsequently, the system loads crucial settings such as date, time, and critical peripheral configurations from the Complementary metal-oxide-semiconductor(CMOS). This battery-powered memory store maintains these settings even when the system is off.
• Various boot loaders are available for Linux, with GRUB (Grand Unified Boot loader) and ISOLINUX (for booting from removable media) being among the most common.
• When starting Linux, the bootloader loads the kernel image and the initial RAM disk into memory. The initial RAM disk contains essential files and device drivers for the system's startup.

3. Boot Loader in Action

The boot loader operates in two main phases:

I. First Stage:

• In BIOS/MBR configured systems, the first boot loader stage is located in the Master Boot Record (MBR) of the hard disk, occupying just 512 bytes.

• This initial stage scans the partition table to identify a bootable partition.

• Upon finding a bootable partition, it locates the second stage boot loader (e.g., GRUB) and loads it into Random Access Memory (RAM).

II. Second Stage:

• The second stage boot loader is found in the /boot directory and presents a splash screen that allows the selection of an Operating System (OS) to boot.

• Once an OS is selected, this stage loads its kernel into RAM and hands over control to it.

• For Linux, the bootloader then loads the compressed kernel image. The kernel's first task is to decompress itself.

• Following decompression, the kernel assesses the system hardware and initializes any necessary hardware device drivers included within the kernel.

4. The Linux Kernel

• The boot loader performs the crucial task of loading the kernel and an initial RAM-based filesystem (initramfs) into the system's memory, allowing the kernel to access it immediately.

• Upon being loaded into RAM, the kernel swiftly undertakes the initialization and configuration of the system's memory. It proceeds to set up all connected hardware components, encompassing processors, I/O subsystems, storage units, and more. Additionally, the kernel is responsible for loading essential user space applications.

5. The Initial RAM Disk

• The initramfs filesystem image contains programs and binary files that perform all actions needed to mount the proper root filesystem, like providing kernel functionality for the required file system and device drivers for mass storage controllers with a facility called udev (for User Device), which is responsible for figuring out which devices are present, locating the drivers they need to operate correctly, and loading them. After the root filesystem has been found, it is checked for errors and mounted.

• The mount program instructs the operating system that a file system is ready for use. It is associated with a particular point in the overall hierarchy of the filesystem (the mount point). If this is successful, the initramfs is cleared from RAM and the init program on the root filesystem (/sbin/init) is executed.

• Init handles the mounting and pivoting over to the final real root filesystem. If special hardware drivers are needed before the mass storage can be accessed, they must be in the initramfs image.

6. /sbin/init and Services

• Once the kernel has set up all its hardware and mounted the root filesystem, it runs the /sbin/init program. This program becomes the initial process, starting other methods to run the system. Most other processes on the system trace their origin ultimately to init; the exceptions are kernel processes, started by the kernel directly for managing internal operating system details.

• Traditionally, this process startup was done using conventions that date back to System V UNIX, with the system passing through a sequence of runlevels containing collections of scripts that start and stop services. Each run level supports a different mode of running the system. Within each level, individual services can be set to run or shut down if running. Newer distributions are moving away from the System V standard but usually support the System V conventions for compatibility purposes.

• Besides starting the system, init is responsible for keeping it running and shutting it down cleanly. It acts as the "manager of last resort" for all non-kernel processes, cleaning up after them when necessary, and restarts user login services when users log in and out.

7. Text-Mode Login/Command Shell

• Near the end of the boot process, init starts several text-mode login prompts (done by a "Getty" program). These enable you to type your username, followed by your password, and eventually get a command shell.

• Usually, the default command shell is bash (the GNU Bourne Again Shell), but several other advanced command shells are available. The shell prints a text prompt, indicating it is ready to accept commands; after the User types the command and presses Enter, the command is executed, and another prompt is displayed after the command is done.

8. X Window System

• Generally, the X Window System is loaded into a Linux desktop system as the final step in the boot process.

• The display manager keeps track of the displays being provided and loads the X server (so-called because it allows for graphical services to applications, sometimes called X clients). The display manager also handles graphical logins and starts the appropriate desktop environment after a user logs in.

The topics we have covered give an idea about what goes into designing, implementing and, ultimately, booting a system. 

Some things to keep in mind:

• System calls provide a direct interface for running programs to request services from the OS at a low level.

• Separation of Policy (what the OS does) from Mechanism (how it does it) ensures flexibility and adaptability in the design.

• Creating an OS for a specific machine setup involves system generation (SYSGEN) and tailoring the OS to the hardware configuration.

• The bootstrapping process initiates system operation, starting with CPU initialization and executing a bootstrap program from firmware. It may directly begin the OS if it's in firmware or load it progressively from storage media into memory for execution.

That’s a wrap! See you in the next issue. Have a great start to the week :)