Module IV

Modern Operating Systems

Case Study (4CS1039)
Syllabus
Linux: Linux Operating System - System Administration and Kernel
Development

Cloud Operating Systems: Google Cloud Platform (GCP) and Kubernetes

Engine.

Real-Time Operating Systems (RTOS): VxWorks, FreeRTOS, and QNX

Linux Operating System
Linux System Administration

Linux system administration involves managing, configuring, and

maintaining Linux-based servers and systems.
Linux System Administration
Key Atreas/Topics:

1. Linux Basics & File System

 Linux distributions (Ubuntu, CentOS, RHEL, Debian)
 File system structure (/etc, /var, /usr, /home, /tmp, /proc, etc.)
 File permissions (chmod, chown, ls -l)
 Hard & soft links (ln, ln -s)
 Disk management (fdisk, lsblk, df, du)

2. User & Group Management

 Adding/removing users (useradd, usermod, userdel)
 Managing groups (groupadd, groupmod, groupdel)
 User permissions (sudo, /etc/passwd, /etc/shadow)
 Switching users (su, sudo, whoami)
Linux System Administration Cntd ..
3. Process & Task Management
 Viewing processes (ps, top, htop)
 Killing processes (kill, killall, pkill)
 Background & foreground jobs (&, bg, fg, nohup)
 Scheduling tasks (cron, crontab, at)
4. Networking & Security
 Configuring IP addresses (ifconfig, ip, netstat)
 Firewall management (iptables, ufw, firewalld)
 SSH remote access (ssh, scp, sftp)
 User authentication (passwd, pam, LDAP)
 Intrusion detection (fail2ban, selinux, auditd)
Linux System Administration Cntd ..
5. Package Management
 Debian-based systems (apt-get, dpkg)
 RHEL-based systems (yum, dnf, rpm)
 Installing software from source (tar, make, ./configure)

6. Log Management & Monitoring

 System logs (/var/log/, dmesg, journalctl)
 Performance monitoring (top, vmstat, iotop)
 Log rotation (logrotate)
 System auditing (auditctl, ausearch)
Linux System Administration Cntd ..

7. Storage Management
 Partitioning disks (fdisk, parted)
 Mounting filesystems (mount, umount)
 RAID & LVM (mdadm, lvcreate, lvextend)
 Filesystem repair (fsck, e2fsck)
8. Backup & Recovery
 Backup tools (tar, rsync, dd, bacula)
 Restoring files (cp, restore, scp)
 Snapshots (lvm snapshots, btrfs)
Linux System Administration Cntd ..

9. Virtualization & Containerization

 Virtual Machines (KVM, VirtualBox,
VMware)
 Containers (Docker, Podman, LXC)
 Kubernetes basics (kubectl, minikube)

10. Automation & Configuration

Management
 Shell scripting (bash, sh, awk, sed)
 Configuration tools (Ansible, Puppet,
Chef)
 Infrastructure as Code (Terraform)
Linux System Administration Cntd ..

11. System Hardening & Security

 Secure boot process (GRUB, UEFI)
 Kernel security (sysctl, AppArmor)
 Secure data transfer (GPG, SSL/TLS)
 Vulnerability scanning (Lynis, OpenVAS)
Cloud
The 4 types of cloud computing
 Private clouds
 Public clouds
 Hybrid clouds, and
 Multi-clouds

The 4 types of cloud services

Within the Cloud deployment models, there are four main services:

1. Infrastructure as a service (IaaS)

2. Platform a service (PaaS)
3. Software as a service (SaaS), and
4. Serverless computing.
Cloud

Cloud Operating Systems (Or rather Cloud Resource Managers)

• Google Cloud Platform (GCP)

• Microsoft Azure
• Amazon (AWS)
• Alibaba
• IBM Bluemix
Containerization
Containerization
A (Docker) container image is a lightweight, standalone, executable package of
software that includes everything needed to run an application: code, runtime,
system tools, system libraries and settings.
 Containers example: Docker, Podman, LXC
 They run on Container (For eg ) Docker Engine.
 Available for both Linux and Windows-based applications, containerized software
will always run the same, regardless of the infrastructure.
 Containers isolate software from its environment and ensure that it works
uniformly despite differences for instance between development and staging.
Kubernetes
What is Kubernetes?
Kubernetes automates operational tasks of container management and includes built-in commands for deploying
applications, rolling out changes to your applications, scaling your applications up and down to fit changing needs,
monitoring your applications, and more—making it easier to manage applications.

Kubernetes is best used for?

Kubernetes is an ideal foundation for developing internal Platform-as-a-Service (PaaS) and serverless* solutions.

Platform engineering teams can use Kubernetes to develop their own higher-level abstractions that allow developers to
rapidly deploy new apps, without learning the intricacies of Kubernetes themselves.
Docker vs Kubernetes
Docker vs Kubernetes?

While Docker is a container runtime, Kubernetes is a platform for running and managing containers from many
container runtimes.

Kubernetes supports numerous container runtimes including Docker, containerd, CRI-O, and any implementation of
the Kubernetes CRI (Container Runtime Interface).

Kubernetes basics (kubectl *, minikube)

kubectl. The Kubernetes command-line tool, kubectl, allows you to run commands against Kubernetes clusters. You can
use kubectl to deploy applications, inspect and manage cluster resources, and view logs.

Minikube is a tool that sets up a Kubernetes environment on a local PC or laptop.

 Linux Kernel Development
Kernel Development
Kernel Development Describes the process of building and maintaining the
core of Linux.

Note: Assembly (any architecture) is not required unless you plan to do

low-level development for that architecture.
 Linux Kernel Development Cntd ..
Kernel Development
Kernel Development Describes the process of building and maintaining the
core of Linux.

Note: Assembly (any architecture) is not required unless you plan to do

low-level development for that architecture.
Linux – Kernel Development
A Sample Case1:
Write a Linux driver for a particular device (say Earphone). The kernel
is written mostly in C, with some architecture-dependent parts written
in assembly.

Sample Scenario2:
Write a Linux driver for a particular device (say an IOT Sensor).
Kernel Development
The thumb rule for all kernel beginners should surely be "make sure that the kernel runs perfectly at
all times on all machines which you can lay your hands on".

The way to do this is to work with others (in the community)on getting things fixed up (this can
require persistence!) but that's fine - it's a part of kernel development.
The
Linux development
kernel development process
in the early
1990’s, with relatively small
users and developers involved. numbers of
With
has a
since
processes user base
had
to to
keep increased,
evolve a the
number
development kernel
of
happening smoothly.
A solid
works understanding
is required
effective part of it. in of
order how
to the
be anprocess
https://docs.kernel.org/6.0/admin-guide/in
dex.html
User-oriented
added
initial to the
section documents
kernel over
contains that
time.
overall have
Thisbeen
information,
describing including
the kernel the
as a README
whole,
documentation on kernel parameters, etc. file
Kernel Patch Releases
The stages that a patch goes through are, generally:

◦ Design. This is where the real requirements for the patch - and the way those requirements will be met -
are laid out. Design work is often done without involving the community, but it is better to do this work
in the open if at all possible; it can save a lot of time redesigning things later.

◦ Early review. Patches are posted to the relevant mailing list, and developers on that list reply with any
comments they may have. This process should turn up any major problems with a patch if all goes well.

◦ Wider review. When the patch is getting close to ready for mainline inclusion, it should be accepted by
a relevant subsystem maintainer. The patch will show up in the maintainer’s subsystem tree and into the
-next trees (described below). When the process works, this step leads to more extensive review of the
patch and the discovery of any problems resulting from the integration of this patch with work being
done by others.
Merging after Review
• Merging into the mainline. Eventually, a successful patch will be merged into the mainline repository managed by Linus
Torvalds. More comments and/or problems may surface at this time; it is important that the developer be responsive to
these and fix any issues which arise.

• Stable release. The number of users potentially affected by the patch is now large, so, once again, new problems may
arise.

• Long-term maintenance. While it is certainly possible for a developer to forget about code after merging it, that sort of
behavior tends to leave a poor impression in the development community. Merging code eliminates some of the
maintenance burden, in that others will fix problems caused by API changes. But the original developer should continue to
take responsibility for the code if it is to remain useful in the longer term.
 How patches get into the Kernel?
The kernel code base is logically broken down into a set of subsystems:
- networking
- specific architecture support
- memory management
- video devices, etc.

Most subsystems have a designated maintainer, a developer who has overall responsibility for the code within that
subsystem.
These subsystem maintainers are the gatekeepers for the portion of the kernel they manage; they are the ones who will
(usually) accept a patch for inclusion into the mainline kernel.

Subsystem maintainers each manage their own version of the kernel source tree, usually (but certainly not always) using
the git source management tool.

Tools like git (and related tools like quilt or mercurial) allow maintainers to track a list of patches, including authorship
information and other metadata.

At any given time, the maintainer can identify which patches in his or her repository are not found in the mainline.
 Next Trees
All the patches which are being prepared for the next merge window?
The answer comes in the form of -next trees, where subsystem trees are collected for testing and
review.

The older of these trees, maintained by Andrew Morton, is called “-mm” (for memory
management, which is how it got started).

The -mm tree integrates patches from a long list of subsystem trees; it also has some patches aimed
at helping with debugging.
 Staging Trees
Staging trees

The kernel source tree contains the drivers/staging directory, where many sub-directories for drivers or
filesystems that are on their way to being added to the kernel tree live. They remain in drivers/staging while
they still need more work; once complete, they can be moved into the kernel proper. This is a way to keep track
of drivers that aren’t up to Linux kernel coding or quality standards, but people may want to use them and track
development.

Greg Kroah-Hartman currently maintains the staging tree. Drivers that still need work are sent to him, with
each driver having its own subdirectory in drivers/staging.

The TODO file lists the pending work that the driver needs for acceptance into the kernel proper, as well as a
list of people that should be Cc’d for any patches to the driver.
 Tools
The kernel development process depends heavily on the ability to herd collections of patches in various
directions. The whole thing would not work anywhere near as well as it does without suitably powerful
tools.

By far the dominant source code management system used by the kernel community is git.

Git is one of a number of distributed version control systems being developed in the free software
community.
It is well tuned for kernel development, in that it performs quite well when dealing with large
repositories and large numbers of patches. It also has a reputation for being difficult to learn and use,
though it has gotten better over time.

Some sort of familiarity with git is almost a requirement for kernel developers; even if they do not use it
for their own work, they’ll need git to keep up with what other developers (and the mainline) are doing.
Real-Time OS
An RTOS is an operating system (OS) for real-time computing applications that processes data and events
that have critically defined time constraints.
A RTOS is distinct from a time-sharing operating system, such as Unix, which manages the sharing of
system resources with a scheduler, data buffers, or fixed task prioritization in multitasking or
multiprogramming environments.
All operations must verifiably complete within given time and resource constraints or else fail safe.
Ad-hoc way
Real-time operating systems are event-driven and preemptive, meaning the OS can monitor the relevant
priority of competing tasks, and make changes to the task priority.

Real-Time Operating Systems (RTOS) example: VxWorks, FreeRTOS, and QNX

Characteristics of RTOS
The most common RTOS designs are:

 Event-driven: switches tasks only when an event of higher priority needs servicing; called preemptive
priority, or priority scheduling.

 Time-sharing: Switches tasks on a regular clocked interrupt, and on events; called round-robin.
VxWorks
VxWorks (RTOS) is for mission-critical embedded systems that must be secure and safe. It delivers a
proven, real-time, and deterministic runtime combined with a modern approach to development.
In Linux all hardware access must be funneled through a device driver. On the other hand, in VxWorks an
application can manipulate the device by writing commands directly to the device's registers.
NASA uses VxWorks - Jet Propulsion Laboratory uses VxWorks for its planetary rover.
Note: An application might access a device using some combination of standard device driver calls and
direct calls.
 Free-RTOS
What is the use of Free-RTOS?
FreeRTOS can be used in embedded systems spanning industrial, commercial, and consumer applications.
For example, smart meters, oil pump sensors, appliances, commercial security systems, fitness trackers, and
sensor networks can all benefit from FreeRTOS.
• The primary purpose of an RTOS is to execute critical operations timely.
• It guarantees that certain processes are completed within strict deadlines, making it ideal for applications
where timing is crucial.
• It is also useful for multitasking an d task-based work.
QNX-RTOS
What is QNX?
QNX is a commercial Unix-like real-time operating system, aimed primarily at the embedded
systems market including automotive, medical devices, robotics, transportation and industrial
embedded systems.
Often uses custom C++ code for control, sensing, data collection, and communication.
QNX is also used in devices where failure is not an option.
Android Vs QNX
Android is a monolithic + layered system optimized for consumer devices with complex user
experiences (phones, tablets).

QNX is a true microkernel OS, highly modular and fault-tolerant, designed for embedded and
real-time critical applications (like cars, medical devices, industrial controllers).
Android Vs QNX - Modularity
Aspect Android System Architecture QNX Architecture

Android is partially modular. It has a layered

architecture: Linux Kernel → HAL (Hardware QNX is highly modular. It is a microkernel-based
Abstraction Layer) → Native Libraries/Runtime OS. Only the absolute core (like IPC, scheduling)
Modularity → Application Framework → Apps. But runs in the kernel; everything else (drivers,
components often have tight filesystems, networking) runs as separate,
interdependencies, especially between restartable user-space processes.
framework and system services.

Android’s modularity has improved over time In QNX, because components are isolated,
System Updates (e.g., Project Treble separated vendor-specific updating or restarting a subsystem (e.g.,
drivers), but full component isolation is still networking) can happen without rebooting the
complex. entire system.

Customization for Devices Android needs heavy modification across many QNX allows for very lightweight, customized
layers for different devices. builds by adding only the needed services.
 Android Vs QNX – Process Management
Aspect Android System Architecture QNX Architecture

Android apps run as Linux processes, and QNX uses user-space servers for almost
each app has its own user ID (sandboxing). everything (file systems, device drivers,
Process Type System services often run in specialized etc.). Processes are first-class citizens
processes but depend heavily on Binder communicating through message-passing
IPC. IPC.

Android isolates apps from each other but In QNX, a crash in one server (e.g., audio
Fault Isolation system services, once crashed, can bring driver) does not crash the kernel or other
down major functionality. Some critical unrelated services. Fault isolation is
services are tightly coupled. stronger because of strict modularity.

Real-Time Capability Android is not real-time by default (even

with PREEMPT_RT patches).
Reference Link

1. The Linux Kernel Module Programming Guide

https://sysprog21.github.io/lkmpg/

2. . The Linux kernel user’s and administrator’s guide

https://docs.kernel.org/6.0/admin-guide/index.html