Module Details and Expectations

Contact Information

• Mike Jones can be contacted via [email protected].
• His office is located in Dalton Building, room 1.19.
• Support is available in the Learning Studio on Wednesdays and Thursdays from 14:00 to 15:00.

Module Details

• Lectures are 1 hour per week.
• Lab sessions are 2 hours per week.
• Semester 2 covers 11 weeks.
• A 15 credit unit equates to roughly 150 study hours, incorporating lectures, labs, and self-study.

Expectations

• Taught sessions should be inclusive and professional
• Students should respect their peers and staff.
• Minimise noise during teaching
• Only register your attendance if you intend to stay for the entire session.
• Arrive quietly if late.
• Seek clarification from staff if needed and follow instructions.
• Taking unauthorized pictures, videos, or audio recordings is prohibited.
• Failure to comply may result in disciplinary action.

Course Resources

• Lecture slides are accessible each week on Moodle, released on Mondays before the lecture.
• Lab notes are also available weekly on Moodle, coinciding with lab sessions.

Assessment

• Assessment is through a Multiple Choice Question (MCQ) format.
• The MCQ will be time-constrained and is scheduled for Week 11 (W/c 7th April 2025).
• Attendance is mandatory for the timetabled Week 11 lab session, non-attendance results in a ZERO grade.
• The MCQ consists of 30 questions, with 28 questions worth 3 points each and 2 questions worth 8 points each.
• 60% of the MCQ focuses on core OS concepts from lectures.
• 40% of the MCQ focuses on the Linux shell practical applications from labs.
• Use of 2 A4 pages (4 sides) of notes are permitted during the MCQ.
• It's highly recommended to prepare notes weekly following lectures/labs.

Communication

• Issues should be raised as soon as possible.
• Communicate at the end of class (if brief), during support hours, via email/Teams, or by appointment.
• For significant issues, submit the appropriate form through the Student Hub.
• Keep updated by regularly checking student email and Moodle

Reading Material

• The suggested textbook is "Operating Systems Concepts".
• The ebook version is on Moodle and the MMU Library.
• The "Linux Labs – BASH Cookbook" is also an ebook on Moodle & the MMU Library.
• Slides and images may be used of "Operating Systems Concepts"

Learning Outcomes

• LO1: Understand and use OS principles.
• LO2: Create shell scripts or programs for OS management.

Module Timeline Topics

• Admin, Overview & History
• Processes & Threads
• Process Synchronization & Concurrency
• CPU Scheduling
• Deadlocks & Livelock
• Memory Management
• Virtual Memory
• File Systems
• File System Implementation
• Protection & Security
• Virtual Machines

Lecture Objectives

• Define the purpose of an Operating System.
• Describe the evolution of Operating Systems.
• Identify key issues in OS design.
• Define system calls and system programs.
• Differentiate between policy and mechanism in OS implementation.

What is an Operating System

• There is no single, universally accepted definition.
• Is “The one program running at all times on the computer”.
• The kernel is the core of the OS.
• Everything else is a system program or an application program.

Purpose of Operating System

• Operating Systems are about resource management: fair and secure sharing of hardware.
• This includes processors, I/O devices, and memory.
• To provide an environment for program execution and services to programs and users.
• This includes preventing errors and improper use, efficient system resource allocation, and user ease of use.

OS Evolution - Background: Von Neumann Architecture

• A general-purpose stored program computer originated in 1945.

Phase 1: Serial Processing (1940s-50s)

• There was no operating system.
• Programmers interacted directly with hardware and signed up for blocks of time.
• There was potential for wasted time with I/O taking a long time resulting in CPU idle time.

Phase 2: Simple Batch Systems (1950s-60s)

• Programmers no longer had direct hardware access.
• Jobs are submitted to a computer operator for batching.
• A resident monitor program manages batch processing sequentially without pauses.

Apollo Program

• NASA contract 1, worked on the guidance, navigation, and control system for the Apollo mission spacecraft.

Relevance to Operating Systems

• Pre-1960s OS were built for individual mainframe computers.
• Smaller computers are more valuable.
• The Apollo Guidance Computer (AGC) was among the first for real-time operation.
• It paved the way for miniaturization and the development of personal computers, laptops and mobile devices.

Phase 3: Multi-programmed Batch Systems (1960s-70s)

• Automatic job sequencing eliminates gaps but the processor can still be idle.
• Slow I/O devices cause wait times.
• Multiprocessing enables switching to another job during I/O waits.
• UNICS (later UNIX) laid the foundation for modern operating systems.

Phase 4: Time-Sharing

• Multi-programmed batch setups can be productive, but do not allow user interaction.
• Time-sharing facilitates user interaction.
• There is balancing maximizing user processing and minimizing response time.

Rise of Unix (1970's)

• Written in C, therefore portable.
• Small, reusable utilities worked together, which made it modular
• Its organization was hierarchical
• Provided a flexible file system.
• UNIX became the basis for Linux, BSD, and macOS.

Key Features of Operating Systems

• User Interface
• Process Management
• Memory Management
• Information Protection & Security
• Scheduling & Resource Management
• Communication
• Error Detection

System Calls

• Are a programming interface to OS services.
• Programs mostly access via a high-level Application Program Interface (API).
• Win32 API is for Windows.
• POSIX API is for POSIX-based systems (*nix, OS X, Android).
• Java API is for the Java Virtual Machine (JVM).
• These act as a bridge between user-mode and kernel-mode operations.

System Programs

• Are software to provide functions, utilities, and services.
• These operate in user space, not part of the kernel.
• These leverage system calls to manage resources.
• Some act as user interfaces to system calls.
• Other system programs functions are:
• File management
• Status Information
• File modification
• Programming-language support
• Program loading and execution
• Communications
• Background Services

OS Structure Types

• Simple
• Layered
• Microkernel
• Modular
• Hybrid

OS Structure - Simple Structure

• There is no well-defined or modularized structure.
• MS-DOS is an example, has no dual-mode operation.
• User programs can directly access hardware.
• One flaw can crash the whole system.

OS Structure - Layered Approach

• OS code is in smaller sections and modular.
• Hardware is the bottom layer, user/application programs are the topmost.
• Layers invoke operations on lower layers, prevents programs from directly accessing hardware.

OS Structure - Microkernel

• The kernel becomes complex as the OS grows.
• An approach that removes non-essential parts from the kernel code, making it smaller and better.
• Process, memory, and communication services are minimal and retained in kernel.

OS Structure - Modular Approach

• Loadable kernel modules are used and the kernel has core services.
• Additional services loadable as modules during runtime/boot.
• Recompiling not needed a new service is added.
• Modules are linked dynamically.
• It's efficient because no need t pass messages/recurrently call lower layers.

OS Structure - Hybrid Systems

• It combines different design elements.
• Monolithic and modular elements mixes to achieve better efficiency.
• It can use layers, microkernels and loadable modules to optimise performance.

Implementing Operating Systems

• Some examples are Windows, Unix(es), Linux, OS X, iOS, Android.
• What should the OS provide (policy)?
• How should it be provided (mechanism)?

Virtual Machines

• Applications traditionally ran on an OS on a computer.
• Virtualisation: applications for a different OS can run through a Virtual Machine.
• (Emulation: applications written for a different platform can be run).
• Virtualisation: allows a safe environment for testing operating systems.

Objectives Recap

• Operating Systems are for resource management.
• Early operating systems handled jobs serially in batches, progressed to parallelism, interactivity.
• Optimising resource utilization and security is the point of modern operating systems.
• System calls and Programs offer the user interface.
• Two pivotal aspects are policies and mechanisms.