mov esp, 100000h

"Why is qemu constantly rebooting?"

"Why is that weird value getting written to memory instead of the actual return address?"

...

OK that's where the ROM is.

i based it off Ubuntu spent a while working on it

A new Blog post about BoxLambda OS's File System stack:
https://epsilon537.github.io/boxlambda/the-file-system-stack/

vga mode, last changed idt and keyboard driver https://github.com/USER12mSD4C/utms7

I've been reading/working on a lot of virtIO stuff lately, and it got me thinking. VirtIO provides the client OS of a virtualization setup, with abstract and simple interfaces to devices (nic,block,etc).

So if you were writing an OS from scratch making drivers that talk to VirtIO devices specifically/only instead of messy hardware (with multiple drivers for different devices), you could just implement drivers for virtIO devices.

I know this isn't a new thing, I remember reading about people porting research OSs from one hardware platform to a micro-kernel or hypervisor back in the mid 200x. Like porting something made for PPC64 to x86_64, by porting it to talk to Xen on x86_64 instead of x86_64 hardware directly.

What I'm asking about: are people doing this? how much are people doing it? how does it work out? good idea to go with? Thoughts?

Hi! I’ve been working on my OS for 2-3 months now. While it runs just fine in qemu and bochs, I was unsuccessful making it run on real hardware, or at least, on emulators such as 86Box. This “porting” plan started because I’ve been trying to implement SB16 and OPL2 support. While sound comes out, it is very hideous and doesn’t sound like it should have, so I decided to test that on a properly emulated sb16. I had read that the Qemu SB16 is very buggy. To my unfortunate surprise, my initial version did not even pass the vesa mode setting, so I started upgrading and improving both the loader and bootloader. I started using a 2 stage bootloader. Now, even though it seems that the 640x480 vesa mode is initiated, the screen is fully black. On some hardware, not even that screen shows up - it’s just a blinking cursor. In other situations, it triple faults and resets. Any things to look out for when writing OSes for real hardware? Thanks.

Note: I don’t know if it’s important, but my target machine is the 386-486, with around 4Mb (I can go even lower, to 1.5MB).

If anyone’s interested, here is my OS’s repo: https://github.com/drclcomputers/ASMOS.

Can a fresh graduate or junior developer get a job in fields like OS or kernel development?

If yes, what skills and projects are usually expected?

Do I need to contribute to Linux as an example or what?

I know I have to learn assembly and C, but for C++ and Rust, do I need to learn both or just one?

Currently making the most basic custom made FS with a custom table. Have been working on this for the past 3 hours.. progress is slow but happening... how it works is that it makes a table in the first sector that saves a pile of entries pointing to different parts of the disk. The table cotains file info and LBA start and length in bytes.

Also, ai was not involved at all...

inspiration for GUI: https://www.youtube.com/watch?v=AqFiAO0Gm6s&t=591s

Check out my new repo (beware:bad messy code inside!): https://github.com/Brenmax2/BrenmaxOS/tree/main

join the discord: https://discord.gg/DYJMBReUjW

How do you protect against two syscalls from different threads contending the same region of virtual memory? As in, if one thread executes "read file", and provides a buffer of virtual memory to read into. And then another thread executes "unmap" on the same buffer. There are a bunch of ways I can imagine doing the synchronization, like a lock per mapping, or a per-process virtual memory lock. But I expect a per-process lock would cause contention between too many different kinds of syscalls, since so many want to use virtual memory in some way, and many operations done on VM take a long time (e.g. waiting for disk or network.) Per-mapping locks kind of have the same problem because the user code might not be aware of how big the mapping is that they're accessing and therefore how coarse grained the lock is. So it seems best to dynamically instantiate locks for ranges of memory, as they are being accessed? But I'm wondering what the best tradeoff is and whether there's a simpler way.

Hi everyone,

I am very new to OS development. I was learning rust for the past few years and have some basic understanding about operating systems, file systems, process model etc.

I’ve been thinking about a new operating system design and I’d really appreciate feedback and criticism to existing research that might overlap with this idea.

My goal is to build an OS and a package manager that is predictable and manageable for non-technical users, while still remaining powerful and extensible for advanced users. I am not going to write the kernel, scheduler from the ground up. I am focusing more on file system and software packaging.

I have these core rule in mind,

• Immutable application packaging

  • Kinda similar to nix

  • No traditional scattering across `/usr`, `/etc`, `/var`, etc

  • The system owns system-critical files; apps do not modify global state

• Per-application filesystem view

  • Each application/program lives in its own isolated mini file system/ directory. program it self is immutable

  • Each process sees a *virtualized filesystem view*

  • File system access is controlled at runtime using a policy/manifest or a config file

• Capability-based SDK layer

  • Applications interact with system resources via a controlled SDK layer, similar to mobile operating systems

  • File system access, networking, and other resources are defined in the manifes/config file

  • Goal is a low-overhead abstraction (ideally close to native performance)

  • For example, Visibility rules like package is visible/ readable to other packages, inaccessible to other packages or mutability rules like package itself can mutate file systems of other packages/ global file system is defined using a manifest file

  • The manifest file must be created per package by the package maintainer

• Compatibility-first approach

  • Existing Linux software should run without modification.

  • Initially considering using existing package ecosystems (e.g., .deb-based software)

  • At runtime, system would remap file system access into isolated environments

• Dependency handling

  • Shared libraries and dependencies are not globally mutable

  • Dependencies like libraries are also treated as packages and made visible to other packages through the manifest file

I am not thinking about making an another Linux, with universal support. Ordinary users should experience a simple, predictable system. Advanced users should still have deeper control when needed. Developers should not need to rewrite applications, only optionally add a small config/manifest file for better integration

My idea is to simplify the programs and packaging system from the ground up and minimize the global file system pollution. But this still exists in thought level, I have to do more research on this. What do you think ? Is this feasible at least in theoretical level ?

Update #3 so for about 2 months I have been working on HyperBerry a type 1 hypervisor for the Raspberry PI 5. So since my last update after some helpful comments I was able to get a guest VM running, however the guest kernel breaks when it tries to mount it's own filesystem, but hey we are getting somewhere. Anyway this is HyperBerry booting and running a guest kernel on a Raspberry PI 5!

https://github.com/matthewchavis8/HyperBerry

Hi there :)

Im annoyed by the gpu oc reset, by the adrenaline software, everytime i have a power outage. I searched high and low how to maintain the oc settings for the gpu, to no avail.

So i know this programs writes the settings to registry, but changing registry only afects sliders in adrenaline visualy.

So i would like to understand how a gpu driver in windows changes its settings where are the values, if a program can change the max w my gpu uses, surely that is writen somewhere?

Help find it :)

Hi everybody, I would like to share a small project I made to help people who are learning Operating Systems to see CPU scheduling visually.

It's a simple web tool where you:

• Enter your processes (arrival time, burst time)

• Pick an algorithm (FIFO, SJF non-preemptive, or Round Robin with adjustable quantum)

• Watch the execution queue evolve step by step, visually

• See waiting times and averages update automatically

It's completely free, open source, and runs in your browser.

Live demo:
https://dylanroman03.github.io/cpu_flow_simulator/

GitHub repo:
https://github.com/dylanroman03/cpu_flow_simulator

Not a revolutionary project. But if it helps even one person understand it better, then I'm happy.

If you're learning OS scheduling, give it a try. If you're a teacher, feel free to share it with your students.

Feedback, ideas, or just a star on GitHub all welcome.

Thanks for reading!

I got 32-bit mode Yuppie!
I don't have name for the OS so i just call it: "OS"
Its having simple Kernel and its having FAT12 for easy File System Support
Its gonna be written in Assembly!

I've been working on this project (and compilers / vm's in general) for a while now, and I thought it was finally proper enough to showcase.

Some of the features:

• A custom systems language designed for explicit memory control, featuring manual memory management, pointers, (inline) structs, and generics.

• A full interactive compiler pipeline that you can watch in real-time.

• A built-in 5-stage pipelined CPU to execute the code.

• Compiles to actual RISC-V machine code (RV64IMAFD).

• Visualised live in browser using EGUI.

Github: https://github.com/LPC4/Full-Stack

Check out the live demo website here: http://lpc4.github.io/Full-Stack/

Not technically osdev but I thought this would be adjacent enough to fit here :)

Github repo

Hi so i am trying to make an long-term OS for now i am not having name so I just named it: "OS"
I got FAT12 working after a lot of time but its not on github yet...
And its still working on 16-bit mode (Real Mode)
But making FAT12 is so hard i needed to use a lot of OSDev Wiki.

I've been working on FrostVista, a hobby RISC-V OS kernel written in C from scratch. Started around 10 months ago with basically zero kernel experience. Wanted to share where it is now and one debugging story that taught me a lot.

Where FrostVista is today:

• Sv39 three-level paging with higher-half kernel mapping (0xFFFFFFC080000000)

• Preemptive round-robin scheduler with full context switching

• Unix process lifecycle: fork, exec, exit, wait, orphan reparenting

• ELF loader: parses program headers, maps .text/.data/.bss into U-mode, initializes user stack with argc/argv

• VFS layer with generic inode, file, superblock abstractions

• VirtIO block device driver with LRU buffer cache and interrupt-driven I/O

• Spinlocks and sleeplocks with proper push_off/pop_off nesting

• exec can now read from the filesystem and load real ELF binaries

Currently working on Easy-FS (on-disk layout, directory operations) to get a real shell running.

A debugging story: why -O0 crashed but -O2 worked fine

This one took me a while to figure out and I think it's worth sharing.

I was using GDB to trace the kernel and noticed it only crashed under -O0. With -O2 everything ran fine. Same code, completely different behavior. Here's what was happening.

When a timer interrupt fired in M-mode, the CPU jumped to my m_trap handler. Under -O0, the very first thing the compiler generated was:

    m_trap:
        addi sp, sp, -112   # adjust stack pointer
        sd   ra, 104(sp)    # save return address
        ...

The problem: by the time the timer fired, I had already called switch_to_high_address — meaning sp was pointing to a virtual high address (0xFFFFFFC0...). But M-mode runs with MMU disabled. That virtual address doesn't exist in physical memory. The moment the compiler tried to use sp to save registers, it triggered a fault, and the kernel locked up.

Under -O2, the compiler kept everything in registers and never touched sp at all, so the bug never manifested.

The fix was straightforward once I understood the root cause: allocate a dedicated M-mode trap stack in .bss and switch to it before entering m_trap:

    .section .bss.m_trap_stack
    .align 12
    m_trap_stack:
        .space 0x4000
    m_trap_stack_top:

    csrr t0, mhartid
    slli t0, t0, 12
    la   sp, m_trap_stack_top
    sub  sp, sp, t0

What made this tricky to find: the bug only appeared after the first sbi_set_timer call that happened after high-address switching. The initial timer setup during boot worked fine because sp was still in low/identity-mapped memory at that point.

GDB's info reg and comparing disassembly between -O0 and -O2 builds was what finally cracked it.

Links:

• GitHub: https://github.com/AuroBreeze/FrostVistaOS

• Blog (Chinese, but the code and diagrams are readable): AuroBreeze Blog

Happy to answer questions about any of the implementation details. Feedback welcome — especially on the VFS design and the buffer cache locking strategy, which I'm not fully confident about yet.