AI d1bf69ce0d Add sysfs VFS driver, SYS_OPEN/CLOSE syscalls, cat app
Sysfs:
- New VFS driver mounted at /sys that lets kernel drivers expose
  virtual text files via namespace registration
- Drivers call sysfs_register(name, ops, ctx) with list/read/write
  callbacks for their namespace
- IDE driver registers 'ide' namespace exposing per-device attributes:
  model, type, channel, drive, sectors, sector_size
- Tested: ls /sys -> ide, ls /sys/ide -> hdd1 cd1,
  cat /sys/ide/hdd1/model -> QEMU HARDDISK

Syscalls:
- Added SYS_OPEN (11) and SYS_CLOSE (12) for file I/O from userspace
- Extended SYS_READ/SYS_WRITE to handle VFS file descriptors (fd >= 3)
- Updated userspace syscalls.h with open()/close() wrappers

Apps:
- New 'cat' app: reads and displays file contents via open/read/close
- Updated 'ls' to accept path argument via ARG1 env var
- Updated shell to pass ARG1 env var to external commands
2026-02-23 14:26:52 +00:00
2026-02-23 11:48:40 +01:00
2026-02-23 10:05:17 +00:00

ClaudeOS

ClaudeOS is an AI-built operating system. It provides a shell and some simple command line utilities to provide a UNIX-like environment.

Technology Stack

The project is written in C, and is built using CMake. It uses Clang as a cross compiler to build the kernel, and Grub to generate a bootable ISO and Floppy image. The kernel is GNU Multiboot compatible.

Target System Requirements

This operating system targets a minimum system containing an 80386 with 4 MiB of RAM. It can boot from either CD or Floppy.

Documentation

Each method and static variable has a Javadoc/Doxygen style comment attached to it describing what its purpose is, and what the expected inputs and outputs are.

In addition, in the docs directory there is a documentation page for each subsystem describing the architecture of the subsystem. This directory can be compiled into an HTML manual.

Testing

There are plenty of unit tests for the kernel that can run directly on the host using the host's compiler, as well as integration tests that are ran within Qemu. Test results from the integration tests can be communicated back to the host using Qemu debug port, which allows the kernel to write the Qemu process' stdout.

Directory structure

The source code uses the following directory structure:

  • apps: contains source code for application. E.g.: app/ls and app/sh live here.
  • build: contains the build outputs.
  • docs: contains structured documentation about the kernel and the applications.
  • libs: contains source code for libraries. Can be used by the applications, and potentially also be the kernel.
  • src: contains the kernel source code.
  • src/it: contains integrations tests for the kernel.
  • vendor: contains 3rd-party source code. AI should never touch this.

Task list

An AI implementing this operating system should implement features in this order. After each feature, it should create a new Git commit and push the commit. The git commit should describe what is done and why certain choices were made. The title of the commit should always end with (AI), to indicate that it was written by an AI. Once a task is completed, it should be checked off.

  • Create directory structure
  • Create initial build system
  • Setup a simple kernel that writes Hello, world to Qemu debug port
  • Update the build system to create both ISO and Floppy images. Verify these work using a test script. The standard CMake build target should automatically generate both images. (Only ISO supported for now)
  • Update the kernel to correctly setup the GDT
  • Create an interrupt handler.
  • Implement a PIC handler
  • Create a physical memory allocator and mapper. The kernel should live in the upper last gigabyte of virtual memory. It should support different zones (e.g.: SUB_16M, DEFAULT, ...) These zones describe the region of memory that memory should be allocated in. If it is not possible to allocate in that region (because it is full, or has 0 capacity to begin with), it should fallback to another zone.
  • Create a paging subsystem. It should allow drivers to allocate and deallocate pages at will.
  • Create a memory allocator. This should provide the kernel with malloc and free. Internally, it should use the paging subsystem to ensure that the address it returns have actual RAM paged to them.
  • Create an initial driver architecture, allowing different drivers included in the kernel to test whether they should load or not.
  • Create a VGA driver. On startup, some memory statistics should be displayed, as well as boot progress.
  • Create subsystem for loading new processes in Ring 3.
  • Update the build script to generate a ramdisk containing any applications to run. This initial ramdisk is in CPIO format.
  • Write a VFS subsystem.
  • Write a VFS driver that provides the contents of the CPIO initial ramdisk to the VFS layer.
  • Create a hello-world app. It should print Hello, World to its own stdout. The kernel should route this to Qemu and to the VGA dispaly. Ensure this work.
  • Implement the fork system call.
  • Implement environment variables. Apps should be able to modify this, and it should be copied to new forks of an app.
  • Create a basic shell program sh. This shell must be able to start the hello-world app. It must include cd as a built-in to change the current working directory.
  • Create an ls app. It should list the contents of the current working directory, via the environment variable.
  • Create a devicefs vfs driver. The devicefs subsystem should allow drivers to create new block devices devices.
  • Create an IDE driver. It should enumerate all IDE devices, and expose them to the vfs driver as hddN or cdN, where N is a number that starts at 1 and increases for each new device. The N value should be calucated by the devicefs subsystem, not the IDE driver.
  • Create an MBR driver. It should be able to automatically detect when new hard drives are detected, and automatically scan them for MBR partitions. Each MBR partition found should be listed as hddNmbrY, where Y is a number determined by the devicefs subsystem.
  • Create a sysfs vfs driver. It should allow drivers to expose text/config files to the VFS. Each driver can request a namespace in the sysfs. E.g.: the IDE driver could request ide. During this registration, the drive must provide a struct containing function callbacks. The callbacks must contain the function list, read, and write. These are executed when the user lists a directory, reads a file, or writes a file. It is expected that the contents of these files are extremely small and can simply be stored on the stack. It should be very easy for a driver to expose new information.
  • Create a FAT32 driver. It should allow reading and writing to and from a block device.
  • Create the mount app. It should allow on to mount a block device using the fat32 driver. Internally, it should use sysfs (which should be mounted automatically by the kernel to /sys) to setup a new mount.
  • Create a floppy driver. Each floppy device should be exposed as /dev/floppyN.
  • Add support for character device to the devicefs subsystem.
  • Create an app called diskpart. This app can be used to modify the MBR partitions on a block device.
  • Create an app called mkfs.fat32. This app can be used to format a block into a FAT32 filesystem.
  • Create a network driver for the NE2000 NIC.
  • Create a network driver for the 3C509B NIC. It should only support RJ45 and 10base-T.
  • Create an ethernet subsytsem. Each ethernet device should be shown as a character device with the name ethN.
  • Create a IPv4 stack. Create the ip app that shows curernt IPv4 configuration. It should read this information from /sys
  • Create a ARP subsystem. Create the arp command that shows current ARP tables. Again, this info should be found in /sys
  • Create a DHCP subsystem. Create the dhcp command to show current DHCP status information.
  • Create a UDP and TCP stack.
  • Implement a simple version of ftp and wget.
  • Create a graphics subsystem. It should provide functionality to switch between the normal text mode, and a graphics mode.
  • Create a simple game of pool. It should use graphics mode to render the game.
  • Create a simple game of minigolf.

Finally, before starting, write your prompt into PROMPT.md. This makes the request that you were given more easily auditable.

Description
An attempt at Vibe coding an operating system
Readme 702 KiB
Working shell Latest
2026-02-23 15:52:50 +01:00
Languages
Dockerfile 100%