MiniOS

MiniOS is a C-based operating systems simulation that models CPU scheduling and memory allocation for a batch of processes described in processes.txt. It is built for users who want to study or demonstrate how a process generator, scheduler, clock, and worker processes coordinate over simulated time.

What makes this repository technically strong is its direct use of operating-system primitives instead of mock abstractions: System V message queues, shared memory, semaphores, Unix signals, and fork/execl are all part of the execution path. The codebase also pairs three scheduling algorithms with buddy-system memory management and produces run artifacts that make the simulation behavior inspectable after execution.

Table of Contents

• Purpose
• Key Features
• Tech Stack
• Architecture
• Installation
• Environment Variables
• Running Locally
• Available Commands and Build Assets
• Main Workflows
• Database Details
• Authentication and Authorization
• Reporting and Analytics
• Testing
• Deployment
• Engineering Notes
• Future Improvements
• License

Back to top

Purpose

This repository implements a miniature scheduler-and-memory-management simulation. In the current design, the process generator reads a workload file and dispatches arriving processes, the scheduler chooses which process runs next and manages memory admission, the clock advances simulated time, and each spawned process consumes its remaining runtime one tick at a time.

Back to top

Key Features

• Interactive scheduling selection in src/process_generator.c for Highest Priority First (HPF), Shortest Remaining Time Next (SRTN), and Round Robin (RR).
• File-driven workload loading from processes.txt through src/loadFile.c, including arrival time, runtime, priority, and memory size.
• Multi-process simulation built on System V IPC, with a message queue between generator and scheduler, shared memory per simulated process, and semaphores for scheduler-process synchronization.
• Buddy-system memory allocation in src/buddySystem_UT.c with power-of-two block sizing and a 1024-byte root memory region.
• Deferred admission of processes that cannot yet be allocated memory through the scheduler waiting queue in src/scheduler.c.
• Execution, memory, and performance reporting through scheduler.log, memory.log, and scheduler.perf.
• Random workload generation utility in src/test_generator.c for producing a fresh processes.txt file.

Back to top

Tech Stack

Area	Technology
Language	C
App type	Multi-process operating systems simulation
Messaging	System V message queues, shared memory, semaphores, and Unix signals
Storage	Text files for input and output artifacts (processes.txt, scheduler.log, memory.log, scheduler.perf)
Project format	Multi-binary C project with shared headers in include/ and models in models/
Build tools	gcc, GNU Make, and VS Code C/C++ launch/tasks configuration

Back to top

Architecture

The codebase follows a process-oriented simulation architecture, where each major concern runs as its own executable and coordinates through IPC.

• src/process_generator.c is the user-facing entry point that loads the workload, prompts for the scheduling algorithm, starts the clock and scheduler, and sends arriving processes to the scheduler.
• src/scheduler.c contains the main scheduling loops for HPF, SRTN, and RR, as well as memory admission, waiting-queue handling, and cleanup logic.
• src/process.c represents the simulated running process; it attaches to shared memory, decrements remainingTime, and signals the scheduler once a clock tick is consumed.
• src/clk.c implements the simulated clock using shared memory and increments the global time once per second.
• src/PGS_MsgQ_Utilities.c wraps the message queue used between the process generator and scheduler.
• src/scheduler_helper.c centralizes process launching, SIGSTOP-based pausing, shared-memory creation, and semaphore setup.
• src/buddySystem_UT.c and models/memoryTreeNode.h implement and model the buddy allocator used for memory placement.
• src/Scheduler_log.c, src/memoryLog.c, and src/scheduler_stats.c generate the persisted execution traces and summary metrics.

Project Structure

repo-root/
|-- Makefile
|-- bin/
|   |-- clk.out
|   |-- process.out
|   |-- process_generator.out
|   |-- scheduler.out
|   `-- test_generator.out
|-- include/
|-- models/
|-- src/
|-- processes.txt
|-- scheduler.log
|-- memory.log
|-- scheduler.perf
|-- MSQKEY
`-- sem

Back to top

Installation

1. Use a POSIX-compatible environment with gcc, GNU make, and System V IPC support. This is required by headers such as <sys/msg.h>, <sys/shm.h>, and <sys/sem.h>, by the use of fork/execl, and by the debugger path in .vscode/launch.json.
2. Clone the repository and open the project root.
3. Build the executables defined in Makefile:

make build

The repository currently includes compiled binaries under bin/, but the Makefile is the authoritative build definition.

Back to top

Environment Variables

This repository does not define environment variables or .env files.

Runtime configuration is driven by repository files and console input:

Input	Purpose
processes.txt	Workload definition loaded by the process generator.
Standard input	Scheduling algorithm choice, plus RR quantum when algorithm 3 is selected.
MSQKEY	ftok seed file used to create the process-generator/scheduler message queue.
sem	ftok seed file used when creating semaphores for simulated processes.

Back to top

Running Locally

To generate a new workload and then start the full simulation, run:

./bin/test_generator.out
./bin/process_generator.out

That sequence matches the make run target in Makefile. If you want to keep the existing workload file, start only the process generator:

./bin/process_generator.out

During execution, the process generator launches bin/clk.out and bin/scheduler.out automatically. When the run completes, inspect scheduler.log, memory.log, and scheduler.perf.

Back to top

Available Commands and Build Assets

Command or Asset	Source	Purpose
make	Makefile	Builds the project because build is the first target.
make build	Makefile	Compiles all five executables into bin/.
make clean	Makefile	Removes compiled .out files, processes.txt, *.log, and scheduler.perf.
make all	Makefile	Runs clean then build.
make run	Makefile	Runs the workload generator, then the process generator.
bin/test_generator.out	Build output	Creates a fresh processes.txt file with randomized process data.
bin/process_generator.out	Build output	Starts the simulation and prompts for the scheduling algorithm.
bin/scheduler.out	Build output	Runs the selected scheduling and memory-management algorithm.
bin/process.out	Build output	Executes a single simulated process instance.
bin/clk.out	Build output	Provides the shared simulated clock.

Back to top

Main Workflows

1. Prepare the workload by editing processes.txt directly or generating it through src/test_generator.c.
2. Start src/process_generator.c, choose HPF, SRTN, or RR, and provide a quantum if RR is selected.
3. The process generator starts the clock and scheduler, then watches the simulated time and sends processes to the scheduler when arrivalTime matches the current clock tick.
4. The scheduler receives incoming processes, creates shared memory and semaphores for them, tries to allocate memory through the buddy allocator, and either admits them to a ready queue or parks them in a waiting queue.
5. The scheduler runs or resumes the next eligible process according to the chosen algorithm, while src/process.c decrements remainingTime and signals progress back through a semaphore.
6. When all processes finish, the scheduler writes aggregate metrics to scheduler.perf and the run artifacts remain available in the repository root.

Back to top

Database Details

This repository does not include a database, ORM, or migration system.

State is handled in three ways:

• Input workload data is stored in processes.txt.
• Runtime coordination data lives in queues, shared memory segments, semaphores, and in-memory structs such as ProcessInfo.
• Persisted outputs are plain-text log and metrics files in the repository root.

Back to top

Authentication and Authorization

This repository does not implement authentication, authorization, roles, or user accounts.

Back to top

Reporting and Analytics

The project includes built-in reporting artifacts rather than a dashboard or service endpoint.

Artifact	Source	Contents
scheduler.log	src/Scheduler_log.c	Per-process lifecycle events such as started, stopped, resumed, and finished.
memory.log	src/memoryLog.c	Allocation and deallocation events, including address ranges.
scheduler.perf	src/scheduler_stats.c	CPU utilization, average weighted turnaround time, average waiting time, and weighted turnaround standard deviation.

Back to top

Testing

This repository does not include an automated unit-test or integration-test suite.

src/test_generator.c is a workload generator, not a verification harness, and no CI configuration files are present in the repository. The current validation path is manual execution followed by inspection of the generated log files.

Back to top

Deployment

This repository does not include deployment manifests, container definitions, release automation, or CI/CD pipelines.

The project is designed to be built and run locally as a POSIX-style simulation.

Back to top

Engineering Notes

• The repository models scheduling behavior with real OS primitives rather than a single-threaded simulation loop, which makes process state transitions explicit and inspectable.
• Scheduling and memory admission are tightly coupled in src/scheduler.c: a process is only moved into a runnable queue after memory allocation succeeds.
• The buddy allocator rounds requested memory to the next power of two for placement, while memory.log records both the requested size and the reserved address range.
• The project is intentionally Linux-leaning: the code uses POSIX process control and System V IPC, src/clk.c invokes ipcrm -a, and .vscode/launch.json points to /usr/bin/gdb.

Back to top

Future Improvements

• Add automated tests for the queue, priority queue, buddy allocator, and scheduler statistics modules.
• Split the scheduling algorithms into separate source files or a clearer strategy boundary to reduce the size and responsibility of src/scheduler.c.
• Replace broad IPC cleanup in src/clk.c with narrower teardown of only the resources created by the current run.
• Add more curated sample workloads and expected-output examples to make algorithm comparison easier during reviews.

Back to top

License

This repository does not include a license file.

Back to top