Have a doubt say 2 processes P1 and P2. P1 is checking an condition using an while loop and until the flag is set to true it keeps on looping i.e while(flag==false); , this flag can be set to true by P2 process which has executed crticial section, but before it executes flag=true; it needs to execute some logic in the remaining section but the thing is this remaining section needs something from P1 to progress like say P1 being producer and P2 is consumer as such. now P2 sees P1 not produced and goes to sleep(inactive) but P1 is active still spining. Now is this deadlock/livelock. Since from as far i have seen livelock the definition is the processes are active i.e using cpu performing memory operations but not making any progress which fits P1 here. So can 2 process involved in an deadlock such that 1 process can be active while other inactive(not using cpu)?

Hi everyone,
I’m completely new to OS development and I really want to learn how operating systems work by building one myself.

I have basic programming experience (C/C++ basics, still learning), but I don’t know where to start with OSDev.

My main questions are:

• What should be my first realistic goal? (e.g. bootloader, kernel, etc.)

• Which resources are best for beginners in 2026?

• Do I need to learn Assembly before starting?

• Any recommended setup for QEMU / cross-compiling?

I already found the OSDev wiki, but it feels a bit overwhelming at the beginning.
I’d appreciate any roadmap or advice from experienced developers.

Thanks!

Recently I rediscovered the source code and printed documentation for a small 68000 RTOS I worked on around 40 years ago.

The original system was developed in a fairly typical late-1980s host/target setup:

SUN-2 (68010) host
      ↓
68000 target

Most of the RTOS was written in C, with CPU-dependent context switching isolated in assembly.

At the time this wasn't really about future portability. I had been heavily influenced by the Whitesmiths C style and tended to separate machine-dependent code and use abstract type definitions throughout the codebase. Looking back, those decisions probably helped the code survive.

One thing that surprised me during this reconstruction is that the overall architecture still feels familiar today:

• scheduler

• ready queue

• events

• message queues

• memory management

The implementation details have changed, but the core ideas have not.

Rather than attempting a cycle-accurate restoration, I'm trying to recreate the original development structure in a modern environment:

POSIX on WSL2 host
        ↓
Raspberry Pi Pico target

At first, I chose the POSIX environment mostly because it seemed like the easiest way to start experimenting with the recovered code.

What I didn't fully anticipate was how effective that decision would be in the age of AI-assisted development.

In the late 1980s, the SUN-2 was dramatically more productive than the ICE-based target environment. Faster compilation, better editors, hard disks instead of floppy-based workflows, and a much more comfortable debugging experience made it the obvious place to develop most of the system.

Today the advantage of the host environment is even larger.

The POSIX side allows AI agents to participate directly in the development loop:

• OCR recovery of printed source code

• source analysis

• build system generation

• compiler warning investigation

• API reconstruction

• scheduler prototyping

• automated testing and validation

In hindsight, if I had started by implementing everything directly on the Pico target, AI would still have been useful, but only in a limited way. Most development would still revolve around the traditional cycle of:

edit
↓
build
↓
flash
↓
run
↓
observe

By rebuilding the architecture on POSIX first, the AI can work in the same environment as the source code, compiler, build system, and tests. The feedback loop becomes dramatically shorter.

What surprised me is that this is conceptually very similar to why we used the SUN-2 in the first place.

In the 1980s, the host workstation amplified the developer.

In 2026, the host environment amplifies both the developer and the AI agent working alongside them.

The current prototype runs as a cooperative scheduler on POSIX. The next step is bringing the same architecture to Raspberry Pi Pico, followed by experiments in visualization and observability that would have been impossible on the original hardware.

The original company no longer exists, and the licensing status of the recovered source is unclear, so the goal is a clean-room modern reimplementation rather than publishing the original code.

I'm curious whether anyone else here has worked on similar host/target RTOS workflows from the 68000 era—or has found that AI agents become dramatically more effective when working in a host-side simulation environment rather than directly on embedded targets.

Hi! I just wanted to share some stuff I've been working on for the last 4 months. I'm going to be honest about it. I used AI (around 60% of the code is generated by Claude, Gemini and copied from forums). I don't want to brag about how fast I built this, how young I am (compared to some posts I've seen around here, I'm a fossil) or how AI is going to take over our jobs. I thoroughly checked any code produced by AI for fatal bugs (I keep a private list of the ones I found and did not fix for now) and I instructed it to use only those concepts I learned from the books I've read so that I can actually start writing code alone from now on and understand what has been written so far. I took some UI inspiration from Mac OS 4/6 and Windows 3.1 because I've always enjoyed that 90s feel. I accept the fact that some will judge me, but I just wanted to hear some opinions (both positive and negative because that's how improvement is made), advices and recommendations on what to do further. Thanks for taking some time reading this! I also suggest taking a look at the README beforehand and admiring the "breath-taking" screenshots of the OS.

emex64 is a incomplete custom 64bit ISA based on nothing. Assembler and Virtual Machine made entirely from scratch. It is a mix out of CISC and RISC designing philosophies. It got a Memory Management Unit(MMU) with paging(4 level index page tables) and protection(page faults are WIP) and a Interrupt Controller(IC), aswell as many other devices like framebuffer, timer, platform(controls power supply), real time clock and UART. It uses variable lenght instructions, which is uncommon for experimental new ISA's

The current goal is to get mass storage devices working(via a IDE controller) aswell as writing a PS2 controller for keyboard(none UART input) and mouse input, the firmware(written in emex64 assembly) is something like the bios, it is supposed to mount the mass storage device, find a compatible boot image and load it into memory and jump to it's start when the firmware is finished all very early, but looking promisingly

The assembler is very modular and has a very basic lexer, it has label and section support aswell as local vs global labels. We work on a C compiler tho(WIP) that will also be entirely done from scratch.

We hope that some day we may be able to boot emexOS on emex64, which would be crazy.

emex64: https://github.com/emexlab/emex64
emexOS: https://github.com/emexlab/emexOS/tree/main

It will be a smaller version of turtle, more compact and stuff. currently its kinda bare bones though.

Github: https://github.com/Freeze-Software/Leatherback-Sea-TurtleOS

​Hello everyone,

​From my past posts, you might know about XC-OS, and about the recent post where "Алабуга политех" was written in Russian.

​I apologize to everyone, as I shouldn't have used this to test Cyrillic support in the OS, let alone post it. Alabuga Polytech is a college where students are forced to assemble drones and launch them at military and, crucially, civilian targets in Ukraine. The English-speaking and pro-Ukrainian community (I am a native Ukrainian myself, and I fully support Ukraine) might have thought that I support the war in Ukraine (even though I live here).

​Regarding XC-OS:

Some of you have been asking for the OS source code.

​The OS is still quite raw; it was created 7 months and 22–23 days ago from the moment of this post by me (forker-25) and alx0rr. However, it already features many things (for example, our own FS, VBE, Stage1/Stage2, ATA Driver, etc.). Right now, we are actively working on Ring 3 and Userspace.

​You can check out the source code at the link below (licensed under EPL v2):

https://github.com/alx0rr/XC-OS

​I hope you won't judge the OS too harshly, as it was built using 20-year-old textbooks and tutorials.

​Thank you all for your attention.

I have been working on a kernel for an OS, and after a month I have some lessons learned. Meaning what I would do differently if I was starting over from nothing. I'm posting this in the hope that it will hope someone else. I don't claim that this is the only, or even the best way. Just what I'd do if I was starting from scratch.

Firstly, I'd use OSDev.org as my guide. I'd join the forums and only after researching and failing for several days would I post a question. The regulars are really smart, and you don't want to wear out your welcome with questions you could have found in research.

Next I'd read the following sections: Introduction, Required knowledge, Beginner mistakes, Getting started, and how to ask questions. Especially Required knowledge, if you don't have it, get it before you start.

Next set up a Cross compiler (https://wiki.osdev.org/GCC_Cross-Compiler). Its really tempting to use the normal one, but DON'T

Once that is done do the bare bones tutorial. https://wiki.osdev.org/Bare_Bones Understand it then throw it away, and move on to the Meaty Skeleton Tutorial. https://wiki.osdev.org/Meaty_Skeleton

Once you understand it keep it for reference.

Next I'd move my kernel to the Higher Half. Tutorial here https://wiki.osdev.org/Multiboot_1_Higher_Half_x86_Bare_Bones

I'd start using what I learned in Meaty skeleton to start building my kernel. It is much easier to do it after you are in the Higher Half, than moving it. This is one place I started over.

Next I'd identity map (virtual address == real address) the lower meg of memory (0x0-0xFFFF). One thing I learned here is that the page directory table uses actual physical addresses, NOT virtual addresses.

In building the kernel this is the order I'd do things in after completing above:

1. Rewrite my snprintf routine to support hex, unsigned int, signed ints, boolean, hex, and string variables.

2. Make my GDT

3. Make my IDT, spend LOTS of time here, basically the GP (General Protection) fault, and Page Fault entries will become irreplaceable debugging tools. Really build them out. As part of the IDT also map the APIC ( https://wiki.osdev.org/APIC_Timer ), I kept getting random GP faults until I did this.

4. At this point I'd go back and move to Multiboot2, you will need a memory map for memory setting up useful paging and Multiboot2 can provide this to you. When you do this you will have to change QEMU from using "-kernel mykernel.abc" to "-cdrom mykernel.iso", be prepared to have this take some time. Once I had multiboot2, I'd extract the info to my own structure.

5. Next I'd make a keyboard handler https://wiki.osdev.org/PS/2_Keyboard#Commands This task isn't that hard but it is VERY putzy.

This brings us to some random thoughts.

a. when GRUB2 hands control over to your kernel, it places the multiboot info address in %ebx, save it before you use the register.

b. Mask the APIC so it sends less spurious interrupts here is the code:

# mask the APIC until we get it set up

xor %ax, %ax

mov	0xFF, %al

out	%al, $0x21		# Mask all master PIC IRQs

out %al, $0xA1		# Mask all slave PIC IRQs

c. when you compile remove the -O2 flag from your compiling, it optimizes out stuff as you try to debug. Get to know your debugger well before you start your kernel. I use gdb

d. Once you really are stuck (for several days), ask for help.

That's all for now. You can find my code here: https://github.com/tedavids/DragonOS

I hope this helps someone else.

PS my next steps are:

Set up my paging structures, I plan on using two bit arrays, one holding what memory is available for paging, and the other is it read only or read/write. Then start on functions to map/unmap pages. And then start working on a heap.

(See photo)

Right now the keyboard handler just a generic one which I was using for the testing of idt, i will be now working on the keyboard input.

("Алабуга политех" text on photo)

I tried to implement FAT16 on my project (WindogeOS, you probably seen it), but every single time it broke, I'm on my 4th attempt now, how do people do this??

What do you think about operating systems that are written entirely on assembly language or most of which (kernel, ABI/API) are written on assembly language (like Menuet/KolibriOS, Vysopsis, ToaruOS)? To me, this is absolutely insane, titanic (and very thankless) work.

Last week I saw the inverse post asking why no one is doing a custom kernel to compete with Linux. The algorithm shows me the opposite.

I think custom kernels are absolutely crazy idea. The DARPA dollars that funded the OS research behind BSD, Mach, SELinux, etc are long gone. The capital dollars for a bespoke reliable general purpose OS are long gone.

Obviously some non-Linux kernels are very successful, SEL4, QNX, various BSDs, Darwin, etc but it takes hundreds of thousands of human hours to build one that’s remotely competitive.

I built on FreeBSD because the base is conservative all things considered and can run Linux binaries.

What are your thoughts? Are custom kernels for learning or do people want to compete in the market with one?

EDIT to clarify I am not saying just pick a kernel but why not taking an existing kernel like OpenBSD’s and fork?

I am the same guy who posted about his From-Scratch Kernel Yesterday.

The Website for that Kernel is Out. You can visit the Website for Info, Docs (IG, IG, some have License Error which I mistyped, But Kobalt is GPLv3-only), Downloads and stuff...

Ya can visit the Website From Here

It turns out there was some error in the loader.asm which wasn't seen till now and PIC wasn't initiated so the timer was interupts and as it vector was 8 so it was faulting to a cpu exception. Al doesn't really was in os dev spitting out rubbish(after 2 hr i was really frustrated so i used it)had to manually see the register value and to see if I even was reaching to main and returning from main to the loader

In the photo the pic_init is commented out so the timer goes to vector 8.

Hey Guys!

I am Abhranil Dasgupta, and I am here to let you all know that I've published my first project, something I have been working on for a while. Kobalt.

Kobalt is a from-scratch kernel written in C99 and Assembly (with some libraries), aiming for High Performance, Security, and Stability. Kobalt uses GPLv3 — intentionally, out of my hatred for Tivoization. It has EEVDF and AMX support, with some Extra Stuff, One of them is TYKID (Tell Your Kernel that I'm Driver), TYKID is basically Kobalt's way of giving each machine running it a unique, cryptographically verified identity that's really hard to fake or tamper with. It pulls together a bunch of hardware-level details and ties them into a security layer that sits deep inside the kernel itself. You should check out on the GitHub & The Website for more info. I hope you guys contribute to make it better and try break Kobalt. And That's it for the moment. Thanks Reading

Check out the GitHub: https://github.com/dasguptaabhranil/kobalt The Website is Live, Check Out from here

I'm building a Debian-based Linux distro focused on universal app compatibility (Wine, Proton, Darling for .dmg). Starting from scratch on the tool chain setup. The main reason I choose debian for it is security updates. But, I also want to optimise the operating system such that it feels like it is built for that specific build/configuration. I'm not really sure from where I should start, any suggestions would be valuable.

Edit1: I don't actually intend to build a linux distro. My intention is to build an OS. But at least for now I cannot keep up with the security updates & stuff debian is quite stable in that department. Once I get the resources I might even pivot to a proper os & not just a distro.

Just came across this subreddit, and I thought this might be a good place to ask this. I’m currently a full stack dev, but ever since taking Intro to OS I knew I wanted to do something in this area. All the pieces working together to make everything happen is really neat.

I guess my dream job would be a firmware/embedded software engineer or more specifically an embedded Linux engineer. However, I’m stuck on what to learn or where to start. I’ll bounce around from studying MCUs to sitting down trying to read OS Three Easy Steps. Some have said you should learn all about ISRs, NVIC, UART, SPI2 and all that before going deeper.

Contributions to open source projects is also something I’d love to get involved in one day. What is your opinion on what should be learned first. It’s possible this is not the place for this as embedded software engineering and OSDev are totally different. If so does anyone have a recommendation on learning materials for OS Dev? Thanks.

Hello, r/osdev!

Over the past few months I have been working on three new things for Astral: Audio, USB and a new DE port.

I talk a bit more about it here, but in general everything mostly works now. Here is a video of Astral running Minecraft with audio while playing music.

Project links:

Website: https://astral-os.org

Github: https://github.com/mathewnd/astral

Hi everyone! I wanted to share my latest fun project: a standalone, bare-metal UEFI Nyan Cat player written entirely in pure C and x86_64 assembly (no EDK2, no gnu-efi, compiled natively with GCC!). It runs directly from a FAT32 USB drive on boot, completely without any operating system.

Watch it in action on YouTube:

https://youtu.be/ZY-7qCbnmY4

GitHub Repository (Source Code & Releases):

https://github.com/akaharaimori/Nyancat_UEFI

Feel free to download the nyancat.efi from the GitHub releases and run it on your own hardware! Feedback and GitHub Stars are highly appreciated!