Files
SparkOS/ARCHITECTURE.md
2025-12-28 15:16:37 +00:00

4.5 KiB

SparkOS Architecture

Overview

SparkOS is designed as a minimal Linux distribution with a custom init system and a modular architecture that allows for future expansion.

System Components

1. Init System (/sbin/init)

The init system is the first process started by the kernel (PID 1). It is responsible for:

  • Mounting filesystems: proc, sys, dev, tmp
  • Process management: Spawning and respawning the shell
  • Signal handling: Reaping zombie processes
  • System initialization: Setting up the initial environment

Implementation: src/init.c

  • Written in C for minimal overhead
  • Statically linked for independence
  • ~100 lines of clean, well-documented code

2. Root Filesystem

Follows the Filesystem Hierarchy Standard (FHS):

/
├── bin/          Essential user binaries (busybox with symlinks)
├── sbin/         System binaries (init, mount, etc.)
├── etc/          System configuration files
├── proc/         Kernel process information (virtual)
├── sys/          Kernel system information (virtual)
├── dev/          Device files (virtual)
├── tmp/          Temporary files
├── usr/
│   ├── bin/      Non-essential user binaries
│   ├── sbin/     Non-essential system binaries
│   ├── lib/      Libraries for /usr/bin and /usr/sbin
│   └── lib64/    64-bit libraries
├── var/          Variable data (logs, caches)
├── root/         Root user home directory
└── home/         User home directories

3. Build System

Makefile: Main build orchestration

  • make init: Compile init system
  • make install: Install init to rootfs
  • make image: Create bootable image (requires root)
  • make clean: Clean build artifacts

Scripts:

  • scripts/build.sh: Quick build for development
  • scripts/setup_rootfs.sh: Create rootfs structure
  • scripts/create_image.sh: Create dd-able disk image

4. Boot Process

Hardware Power-On
    ↓
BIOS/UEFI
    ↓
Bootloader (syslinux)
    ↓
Linux Kernel (vmlinuz)
    ↓
Init System (/sbin/init) [PID 1]
    ↓
Mount filesystems
    ↓
Spawn busybox sh shell
    ↓
User interaction

Design Decisions

Why Custom Init?

  • Simplicity: No dependencies, easy to understand
  • Control: Full control over boot process
  • Size: Minimal footprint (<1MB statically linked)
  • Learning: Educational value for OS development

Why Static Linking?

  • Independence: No library dependencies
  • Portability: Works on any Linux system
  • Reliability: No missing library issues

Why Busybox?

  • Minimal: Single binary provides dozens of utilities
  • Small footprint: Typically <1MB for full feature set
  • Efficient: Less memory and storage overhead than full GNU coreutils
  • Standard: De facto standard for embedded Linux systems

Future Architecture

Planned Components

  1. Qt6/QML GUI

    • Full-screen Wayland application
    • Android-like interface design
    • Desktop-oriented workflow
  2. Wayland Compositor

    • Custom compositor for SparkOS
    • Minimal resource usage
    • Touch and mouse support
  3. C++ CLI Tools

    • System management utilities
    • Package management
    • Network configuration
  4. Sudo Integration

    • Proper privilege elevation
    • Security policies
    • Audit logging

Security Considerations

  • Static binaries reduce attack surface
  • Minimal running processes
  • Root filesystem can be read-only
  • Future: sudo for privilege escalation
  • Future: SELinux/AppArmor integration

Performance

  • Fast boot time (seconds, not minutes)
  • Low memory footprint (~50MB base system with busybox)
  • No unnecessary background services
  • Efficient init system

Portability

  • AMD64 architecture (x86_64)
  • dd-able disk images
  • USB flash drive ready
  • Future: ARM64 support

Extension Points

The architecture is designed for easy extension:

  1. Init system: Can be enhanced with service management
  2. Filesystem: Can add more mount points and partitions
  3. Boot process: Can integrate other bootloaders
  4. GUI: Clean separation allows GUI to be optional

Development Workflow

  1. Modify source code in src/
  2. Build with make init
  3. Test init in isolation
  4. Install to rootfs/ with make install
  5. Create test image with sudo make image
  6. Test on real hardware or VM

References

  • Linux Kernel Documentation
  • Filesystem Hierarchy Standard (FHS)
  • POSIX Standards
  • Qt6 Documentation
  • Wayland Protocol Specification