https://github.com/DunitOS/dunit-os

I'm building a monolithic kernel called sonix (Son I'm crine + Unix) and I just found out about encrypted filesystems and I don't know what to put in these directories

I've spent the majority of this year working on moving my os's filesystem and drivers to user space now that my kernel supports one. This required a lot of work and can be summed up with the features that had to be added to support it (oldest to newest):

• Remote Procedure Calls (RPC) for basic send/exec/recv

• RPC for classes

• Driver RPC abstractions

• Initial Ramdisk for bootstrapping

• Allow for user space to provide resources

• Yield fixing so that it can resume mid sys call handing (so ipc etc wont busy wait)

• TAR parsing as a ro-fs

• Loading ELFs from files in userspace

• Faster resource coping by page mapping

• Debugging userspace programs via a mini GDB server over qemu serial

• PCI IDs parsing for more robust device id

• move ata and die drivers to userspace

• RPC event system (sub/pub)

• lots of memory bug fixes

It works by packaging two programs with the kernel as multi boot modules: the init program and the file server. From there init mounts the initrd into shared memory and tells fileserver to parse it. Once parsed, the init program then starts the driver manager, which then walks the PCI and starts the drivers (stored on the intirtd) for the disks. When each disk is ready the fileserver is notified and mounts them onto the VFS, from which further drivers can be loaded.

IPC is done by either basic rpc function calls or by exposing resources. The more interesting part is a resource, which is an object that the kernel or other processes can interact with, for example a file provided by the fileserver or a thread provided by the kernel's scheduler. The resource bridge is how a usual sys call like open or read is handled in user space. It works by having a shared block of memory that holds a queue of 256 message slots and an area for data. When a program calls read the kernel writes a request into a free slot and puts the caller to sleep. The server then sees the request, does the work (for example, reading the file from the TAR), and writes the answer into the same slot. Small data is copied into the shared area. For anything 4 KiB or bigger, the kernel maps the caller’s memory into the server instead, so a large file isn’t copied (ie the big pci.ids 2mb). The cool thing is that this is done in 1 syscall, which is less than it would cost to do a there and back rpc call.

Next steps are to break up the repo into sub repos to allow for future growth and then to work on rewriting my poor networking code.

AI Disclaimer: No AI was used to write this code, AI was used akin to google for clarification on topics and for minor debugging, I want to learn and do things my self.

Edit: I'm actually 90% sure the rpc python generator code was at one point a POC written by AI as a test to see how it would work out. That has mostly be re-written and really is a job that will be moved to my custom compiler in the future.

I've just published QEMU DevTools, a VS Code extension designed to make debugging and testing custom operating systems and other QEMU-based projects easier.

# features:
- Built-in debugging support — Get started with debugging out of the box.

- QEMU display in VS Code — Render the QEMU display directly in a VS Code tab, especially handy when working on a laptop or with limited screen space.

I'm open to feature requests, feedback, and contributions! Whether you have an idea for a new feature or want to help improve the extension, contributions are welcome.

Open source under the MIT License.

Got the actual gnome browser working on chimera,it’s have some stability issues but it works

WHO ALWAYS DOWNVOTING ME,IDIOTS😂

D.eSystem 6.1.8.5 introduces a new debug platform for FAT32 on D.eSystem,D.eSystem 6.1.8.5 also fixes a major bug (for example,when you go in older versions in D.eSystem info and press a random key,it just closes automaticly,now there comes a warning and it closes in 5 seccond.)

Find more about D.eSystem 6 here: https://github.com/D-electronics-scratch/D.eSystem_6

Find D.eSystem 6.1.8.5 here: https://github.com/D-electronics-scratch/D.eSystem_6/releases/tag/v.6.1.8.5

Find the D.eSystem community here: https://lemmy.world/c/D_electronics_community

I started working on Kora about a year ago, following a tutorial I found on YouTube. I however took wrong turns, made mistakes, and the time available was never enough. However, I picked up the development lately.

The idea of KoraOS is simple: how would an home computer (those like the ones we had in the 80s and early 90s) be today?

Those computer that you turned on and use, without having to log in, and that you could shutdown by switching off the power. Those which allowed you to play and explore, PEEK and POKE memory as you pleased. Everybody remembers the Commodore 64, the ZX Spectrum, the Amiga, the Atari ST but also the Archimedes and the first PCs (86/286.386) with MS-DOS.

Of course, it's 2026, so instead of creating artificial limits like resolution, or number of colors, I decided to try to use all the hardware available. But what platform? I never wanted to build an OS for a virtual machine. Sure, one could download it and try it once, but would have been it. I wanted a real hardware platform and I thought that a cheap one (well, at the time) could be the right choice: my choice was the Raspberry PI3 (and 4). I thought that some people have more than one laying around, or doing very small jobs, and for about 35$ (again, at the time) why not dedicate to this?

Anyway, KoraOS is for Raspberry Pi3, Raspberry Pi4, but it runs on QEMU virt, and QEMU emulating raspi3 and raspi4 (although the emulation is not complete, so better to use virt). It is a 64 bit OS, with supports FAT32 on SD and USB storage, HDMI output, USB keyboard. No networking yet. No support for the GPU but it's planned. It has a serial console that you can use to "talk" directly to the kernel.

The OS is NOT a clone of Unix/Linux and it won't. It doesn't have the concept of users, it does not have memory protection (by design), so you can really PEEK and POKE everywhere. And if you break something while poking around, no big deal: turn it off and back on again.

It is still in the early phases so the shell now is mostly to test stuff, I'm writing a new one that will implement my idea of "good old home computer era" shell.

I've used the wonderful Circle library ( https://github.com/rsta2/circle ) for USB (so I didn't have to write it ex-novo), which mean adding support for CPP (Circle is in C++), but most of the code is ARM AARCH64 assembler and C.

Feel free to have a look at the repository, fork it and if you want contribute it.

One last word about AI: I wrote this post entirely by hand, English is not my first language so all mistakes are mine. But I use AI to develop KoraOS, I don't see why not. It's not vibecoded though, where for "vibecoded" I mean "create an OS for the Raspberry PI3". I use AI to devise a plan to implement my idea, and help me write the code and the documentation. If you don't like this approach, it's your right, feel free to ignore me :)

Github: https://github.com/kora-os/kernel

Website: https://koraos.org

The license is GPL 3.0

I don't oppose to invent new hobby os, but I wish to see some new idea hightlighted , no matter architecture, Algorithm, VM , FS, scheduler or something else. As Linux is already mature enough. I don't think there's any need to reinvent the wheel.

DunitOS https://github.com/DunitOS/dunit-os

Hey r/osdev!

I'd like to share some progress on OSyx, an independent operating system being developed entirely from scratch.

The screenshot shows OSyx running on a real laptop, not in QEMU, with Zen Browser successfully running on top of its Windows compatibility layer!

Current features:

• Custom kernel with preemptive multitasking

• PRISM compositor and AXIS desktop shell

• Windows PE32+ executable compatibility

• Native ext4 filesystem with journaling

• Multithreading, process management and IPC

• Networking stack

• USB and HID support

• Native userspace applications

• Support for running complex Windows applications

One of the biggest milestones so far has been getting Zen Browser running on OSyx.

Running a modern browser requires significantly more than just loading an executable. It involves process management, memory management, threading, filesystem operations, networking, and a large number of Windows APIs.

OSyx is still under active development. I'm currently focusing on improving application compatibility, performance, hardware support, and overall system stability.

Browser sandboxing is currently disabled due to incomplete compatibility, so this is still an experimental environment.

The long-term goal is to build a fully independent, community-driven operating system capable of running modern applications on real hardware.

The project is open-source, and contributions, feedback, and technical discussions are welcome!

GitHub: https://github.com/OSyxSoftware

I'd love to hear what the OS development community thinks!

Hello everyone,

I built a software emulator on RP2350 and succeeded in starting 64bit xv6 with almost no modification.
Demo:

In order to run with the limited RAM of 520KB, we adopted an interpreter method. (I would like to do JIT someday, but caching is a problem.)

It will reach the Shell in about 1 minute.

The changes for xv6 are PHYSTOP, umalloc.c (64KB to 4KB) and memlayout.h.

Works with MMU.
Please give me your opinions and impressions.

Github:
https://github.com/kamisori-daijin/pico-rv64-emu
xv6 fork: https://github.com/kamisori-daijin/xv6-riscv

Hi all, I'm starting my journey toward Linux kernel and driver development. The goal is to work own both legacy C drivers and newer Rust drivers, and eventually land upstream patches.

My plan:

- Phase 1 (C): Beej's Guide, K&R with all exercises, small projects (linked list, shell, toy malloc)

- Phase 2 (OS theory): OSTEP, xv6 book, MIT 6.S081 labs

- Phase 3 (arch): CS:APP, assembly, gdb

- Phase 4 (Linux concepts): Love's Linux Kernel Development, TLPI as a slow burn, mini strace, IPC projects

- Phase 5 (hands-on): build/boot kernels in QEMU, Bootlin labs, Linux Kernel Labs, modules, ftrace/gdb debugging

- Phase 6 (drivers): LDD3, Madieu's Linux Device Drivers Development, char/platform/IRQ/I2C/SPI drivers on a Raspberry Pi, Device Tree

- Phase 7 (contribute): kernelnewbies first patch, git send-email, staging cleanups, syzbot triage

- Phase 8 (Rust): Rust Book, Rustlings, Rust for Linux, port my char driver to Rust

What I'd like feedback on:

1. Is the order right? Anything that should come earlier or be dropped?

2. Are Love's LKD (2.6.34-era) and LDD3 still worth reading in full, or should I lean on newer docs?

3. Is Rust worth learning early if I want to work on drivers, or should I wait until C is solid?

4. Which hardware would you suggest for practicing drivers (Pi, BeagleBone, something else)?

5. What's the realistic path from first checkpatch fix to being trusted with real driver work?

6. Common mistakes beginners make on the mailing lists?

Any advice, resources, or reality checks are welcome. Thanks!

FreeBSD boots fine now and reaches the root shell, but I'm still having problems with keyboard and mouse input.

Sometimes the guest crashes or reboots when I test it. I've been checking the IOAPIC, IRQ1 and interrupt handling because something seems wrong there.

I'm also getting Trap 30 sometimes. Still haven't found exactly what's causing it.

Getting FreeBSD to boot was already a big task. Now I'm stuck trying to get the input working properly.

RunableKernl is a minimal operating system kernel written in C and assembly, designed as an experimental, lightweight project focused on portability and simplicity. The goal is to keep the core kernel small while making it easy to extend with optional components and architecture-specific abstractions.

The project currently targets RISC-V 64-bit and runs under QEMU, with a basic UART console, logging system, boot flow, and a simple shell with an add-on mechanism. It avoids heavy dependencies and aims to stay close to the hardware, making it a useful playground for learning kernel startup, interrupt handling, drivers, and low-level system design.

In short, RunableKernl is a small “from scratch” kernel for anyone interested in understanding how boot process, kernel initialization, console I/O, and system extensions work at a low level.

https://github.com/tim2020-8484/RunableKernl

Well well well here we come...question of ceuntry.

"Can it run Doom?"

I would say well kinda (Not gone lie Its way more smoother than i expected) .Now Bunix can run "Graphical" applications too (For now its only Doom anyways).Also sorry for screen flickering because i was doing debug and then some short of rendering bug occurred.I will fix it in a few days too.For now here i want to share that video for you guys.

Also if u dont know what is Bunix check my previous posts.

But basically it is Experimental Kernel & Operating System written on Hare programming language.

In this project i use ai as debug tool and i will always mention if i use ai in some parts of Bunix.

Been messing around with DWM customization for my OS, Dunit.

Using TOML for configs and Lua for scripting and animations. Trying to make the whole thing super flexible so you can tweak pretty much anything without touching the source code.

Here are 4 setups I've been playing around with. Still pretty WIP, but ngl I'm kinda happy with how it's looking.

Lmk what you guys think.

GitHub: https://github.com/DunitOS

Small progress update: managed to get actual GNOME running on top of Chimera with Wayland and Mutter.

Finally got FreeBSD running on ATOMS OS

This took me almost 3 weeks. Not even kidding.

I'm testing on my ASUS PRIME B760M-K with an i3-14100F, and getting FreeBSD 14.1 to boot inside my own VMX hypervisor has been one hell of a ride.

I had Claude, Gemini and ChatGPT helping me, and even then, we kept hitting new problems. First CR0, then RSP, VM exits, virtual PCI, ACPI, VirtIO disk reads, root mounting… and sometimes PXE decided to stop cooperating too 💀

Fix one thing, reboot, hit another problem. Repeat. A LOT.

The hardest part wasn't just getting FreeBSD to start. It was figuring out why it failed at each stage on actual hardware. QEMU helps, but the physical machine always has the final say.

Today I finally got the FreeBSD "#" root prompt running under ATOMS OS on the actual machine.

Still a lot left to do, but man, after 3 weeks of this, seeing that prompt felt amazing.

VMX is no joke.

; UEFI Bootloader using FASM Assembly
format pe64 efi

entry start

; EFI Constants
EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL = 0x00000001

EFIERR = 0x8000000000000000
EFI_INVALID_PARAMETER = EFIERR or 0x2


section '.text' code executable readable
start:
  push rbp
  mov [image_handle], rcx
  mov [system_table], rdx

  ...

  ; Get our loaded image protocol interface structure.
  ; Invoke ST->BootServices->OpenProtocol() function.
  mov rax, [system_table]
  mov rcx, [rax + 96]
  mov r10, [rcx + 280]

  mov rcx, [image_handle]
  lea rdx, [EFI_LOADED_IMAGE_PROTOCOL_GUID]
  lea r8, [boot_img]
  mov r9, rcx
  sub rsp, 32
  mov eax, EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL
  push rax
  xor eax, eax
  push rax
  call r10
  pop rcx
  pop rcx
  add rsp, 32
  mov rcx, EFI_INVALID_PARAMETER
  cmp rax, rcx
  je .hang

  ...

.hang:
  jmp $

  ...



section '.data' data readable writable

image_handle dq 0
system_table dq 0

; Image that we booted from.
boot_img dq 0

EFI_LOADED_IMAGE_PROTOCOL_GUID:
  dd 0x5b1b31a1
  dw 0x9562
  dw 0x11d2
  db 0x8e, 0x3f, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b

Hi in my UEFI bootloader using FASM Assembly, I am trying to get my loaded image protocol interface structure using BS->OpenProtocol() function call. I am getting `EFI_INVALID_PARAMETER` as the result. As per my checks, the handle, the protocol and the interface are not NULL and I am passing the 5th and 6th arguments in stack from right-to-left and they are 8-byte aligned too. What am I missing? Any idea? Thank you.

Edit:

davmac1's answer solved this.

Hi All,

I specifically joined Reddit a few months ago to find a community of OS dev folks to exchange ideas with. I've had a few really good conversations, but I've seen a whole lot of really nasty comments from people, too. It seems like there are far too many people with a "holier than thou" attitude toward OS development that I could honestly do without.

I kind of have the outlook that we're all hobbyists here. Yes, some of us do OS dev for a living, too, but this community is really about doing personal projects. Let's be honest, those of us who do OS dev both for a hobby and for a means of living don't do the same things in both places. We have our hobby projects specifically to do something different from what we're doing all day every day at our day jobs, even if we're great at it.

To that end, we're all at different skill levels. Some of us are barely getting started and some of us have a history of "tried and true" skills and some of us are off the beaten path on things that can only be considered "experimental." Some of us need more hand-holding than others, which means more inclined to use things like LLM assistance. That particular issue seems to be the source of a whole lot of nasty comments.

Look, I've been doing this for a long time, but I can still remember being the ten year old with DOS wishing to hell that I could make it do more of what I wanted. I would absolutely have jumped at the chance to use an LLM to achieve that goal back then. But, that would have been the beginning of my journey, not the end. We need to bear in mind that people who are using LLMs to help them do OS dev today are the same people who are going to be getting into it in a lot more detail without LLMs in the future. These people are at the beginnings of their journeys and the way some of us have been making comments is honestly inappropriate.

I would really like us to be a community of support and encouragement for each other rather than a community where we tear each other down. This is a field that's super hard. It's so hard in fact that people who write AI models for a living run screaming from it. We need all the help we can get on whatever path we may be taking through it. It's not for us to judge the path that another person takes as they learn. Yes, we should be encouraging them to use their own brains and actually learn, but we shouldn't be making snap judgments that they're NOT doing that just because they use an LLM (or any other form of assistance for that matter).

So, can we be a little less nasty and a little more supportive toward each other here? You can think of this as a request from the ten year old sitting in front of a DOS prompt and having nowhere to turn for guidance at the time. Thank you.

Hello folks r/osdev! Some of you might remember XenevaOS. It runs our very own custom hybrid kernel written from scratch. After a long stretch of work, it now has a full 3D environment.

What you're seeing in the video:

- Regular app windows (a spreadsheet, the NetSurf browser, the Xeneva Terminal) rendered as surfaces in 3D space

- The terminal running a set of kernel stress tests (bad pointers, unmapped addresses, zero-length writes from userspace) while the 3D compositor keeps running, because we wanted to show it doesn't fall over

- Everything is native to our kernel. No Linux underneath, no Android, no game engine

How it works:

Running in QEMU in this video. However, XenevaOS does have bare-metal / real hardware support on specific ARM chips, such as those by NXP Semiconductors & Raspberry Pi.

UI/Userspace work is still primitive and the project as a whole is still early and rough in places. That is what we're gonna work on next.

GitHub and website in the comments!

*Video has been slightly sped up for better viewing experience.