My-Operating-System-OpenOS

OpenOS - Modular Monolithic Architecture

Overview

OpenOS has been refactored from a flat directory structure into a clean, modular monolithic architecture. This document describes the new architecture, design principles, and module organization.

Architecture Philosophy

OpenOS follows a monolithic kernel architecture with strong modularity:

Directory Structure

OpenOS/
├── arch/                   # Architecture-specific code
│   └── x86/               # x86-specific implementations
│       ├── boot.S         # Multiboot entry point, stack setup
│       ├── idt.c/h        # Interrupt Descriptor Table
│       ├── isr.S/h        # Interrupt Service Routines
│       ├── pic.c/h        # Programmable Interrupt Controller
│       ├── ports.h        # x86 port I/O operations (inb/outb)
│       └── exceptions.c/h/S  # CPU exception handlers
│
├── kernel/                # Core kernel subsystems
│   ├── kernel.c/h         # Main kernel entry and initialization
│   └── panic.c/h          # Kernel panic handler
│
├── memory/                # Memory management
│   ├── pmm.c/h            # Physical Memory Manager (page allocator)
│   ├── vmm.c/h            # Virtual Memory Manager (paging)
│   └── heap.h             # Kernel heap allocator (placeholder)
│
├── drivers/               # Hardware drivers
│   ├── console.c/h        # VGA text mode console
│   ├── keyboard.c/h       # PS/2 keyboard driver
│   └── timer.c/h          # Programmable Interval Timer (PIT)
│
├── fs/                    # File system support
│   └── vfs.h              # Virtual File System (placeholder)
│
├── process/               # Process management
│   └── process.h          # Process structures (placeholder)
│
├── ipc/                   # Inter-process communication
│   └── (future)           # Pipes, messages (future)
│
├── include/               # Common headers
│   ├── types.h            # Standard type definitions
│   └── multiboot.h        # Multiboot specification structures
│
├── Kernel2.0/             # Output directory (legacy compatibility)
│   └── openos.bin         # Final kernel binary
│
├── Makefile               # Build system
├── linker.ld              # Linker script
└── grub.cfg               # GRUB bootloader configuration

Module Dependencies

The kernel maintains a strict dependency hierarchy to prevent circular dependencies:

┌─────────────────────────────────────────┐
│           User Space (future)           │
└─────────────────────────────────────────┘
                   ▲
                   │ syscalls
┌─────────────────────────────────────────┐
│         Core Kernel (kernel/)           │
│   - kernel.c (initialization)           │
│   - panic.c (error handling)            │
└─────────────────────────────────────────┘
         ▲              ▲              ▲
         │              │              │
┌────────┴─────┐ ┌─────┴──────┐ ┌────┴─────┐
│   Drivers    │ │   Memory   │ │   FS     │
│   (drivers/) │ │  (memory/) │ │  (fs/)   │
│ - console    │ │ - pmm      │ │ - vfs    │
│ - keyboard   │ │ - vmm      │ │          │
│ - timer      │ │ - heap     │ │          │
└──────────────┘ └────────────┘ └──────────┘
         ▲              ▲              ▲
         │              │              │
         └──────────────┴──────────────┘
                   │
         ┌─────────┴──────────┐
         │   Architecture     │
         │   (arch/x86/)      │
         │ - boot.S           │
         │ - idt              │
         │ - isr              │
         │ - pic              │
         │ - exceptions       │
         │ - ports            │
         └────────────────────┘
                   │
         ┌─────────┴──────────┐
         │   Common Headers   │
         │   (include/)       │
         │ - types.h          │
         │ - multiboot.h      │
         └────────────────────┘

Dependency Rules

  1. Upward dependencies only: Lower layers don’t depend on upper layers
  2. Common headers: All modules can include types.h and multiboot.h
  3. Architecture isolation: Only arch/ directly uses hardware-specific code
  4. Driver independence: Drivers don’t depend on each other
  5. Kernel coordination: kernel/ coordinates between all subsystems

Module Descriptions

Architecture Layer (arch/x86/)

Purpose: Hardware abstraction and x86-specific operations

Key Components:

Responsibilities:

Core Kernel (kernel/)

Purpose: System initialization and core kernel services

Key Components:

Responsibilities:

Memory Management (memory/)

Purpose: Physical and virtual memory management

Key Components:

Responsibilities:

Drivers (drivers/)

Purpose: Hardware device drivers

Key Components:

Responsibilities:

File System (fs/)

Purpose: File system abstractions (future)

Key Components:

Responsibilities:

Process Management (process/)

Purpose: Process and thread management (future)

Key Components:

Responsibilities:

Common Headers (include/)

Purpose: Shared type definitions and structures

Key Components:

Responsibilities:

Design Patterns

1. Initialization Pattern

All subsystems follow a consistent initialization pattern:

void subsystem_init(void) {
    // 1. Initialize internal state
    // 2. Configure hardware (if applicable)
    // 3. Register interrupt handlers (if applicable)
    // 4. Enable operations
}

2. Interface Segregation

Each module exposes a minimal public interface:

// In header file: Public interface
void driver_init(void);
void driver_read(void *buffer, size_t size);
void driver_write(const void *buffer, size_t size);

// In C file: Internal implementation
static void internal_helper(void);
static int internal_state;

3. Hardware Abstraction

Hardware access is isolated to specific modules:

Application Code
       ↓
   Driver API (console_write)
       ↓
   Driver Implementation (drivers/console.c)
       ↓
   Port I/O (arch/x86/ports.h)
       ↓
   Hardware

Naming Conventions

Files

Functions

Header Guards

Constants

Build System

Makefile Organization

The Makefile is organized by directory:

# Architecture objects
ARCH_OBJS = arch/x86/boot.o arch/x86/idt.o ...

# Kernel objects
KERNEL_OBJS = kernel/kernel.o kernel/panic.o

# Memory objects
MEMORY_OBJS = memory/pmm.o memory/vmm.o

# Driver objects
DRIVERS_OBJS = drivers/console.o drivers/keyboard.o ...

Include Paths

The build system provides include paths for all major directories:

CFLAGS += -I./include        # Common headers
CFLAGS += -I./arch/x86       # Architecture headers
CFLAGS += -I./kernel         # Kernel headers
CFLAGS += -I./memory         # Memory headers
CFLAGS += -I./drivers        # Driver headers

Build Targets

Future Extensions

System Calls

System calls will be added in the kernel/ directory:

kernel/
├── syscall.c/h          # System call dispatcher
├── syscall_table.c      # System call table
└── syscall_handlers.c   # System call implementations

Scheduling

Process scheduling will be added in kernel/ and process/:

kernel/
└── scheduler.c/h        # Scheduler implementation

process/
├── process.c            # Process management
└── context.S            # Context switching

Virtual File System

VFS will be fully implemented in fs/:

fs/
├── vfs.c/h              # VFS core
├── ramfs.c/h            # RAM-based FS
└── devfs.c/h            # Device file system

Benefits of This Architecture

1. Simplicity

2. Performance

3. Control

4. Learning Clarity

5. Expandability

Comparison: Before vs After

Before (Flat Structure)

Kernel2.0/
├── boot.S
├── kernel.c
├── idt.c/h
├── pic.c/h
├── isr.S/h
├── exceptions.c/h/S
├── pmm.c/h
├── vmm.c/h
├── keyboard.c/h
├── timer.c/h
└── linker.ld

Issues:

After (Modular Structure)

├── arch/x86/          # Hardware abstraction
├── kernel/            # Core kernel
├── memory/            # Memory management
├── drivers/           # Device drivers
├── fs/                # File systems
├── process/           # Process management
└── include/           # Common headers

Benefits:

Conclusion

This modular monolithic architecture provides OpenOS with a solid foundation for growth while maintaining the performance benefits of a monolithic kernel. The clear structure makes it easier for developers to understand, maintain, and extend the system.

References

This site is open source. Improve this page.