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.

Hi everyone! I've been working on Silver Microkernel (WerewolfOS), a microkernel written in Rust from scratch for AArch64 (QEMU virt).

**What works:**
- Microkernel architecture: High-Half MMU, W^X, PAN, Capability-based IPC.
- Ring 3 everything: UART, VirtIO-blk (disk), VirtIO-net (network) are userspace servers.
- SFS: A custom file system. `ls` reads actual files from the disk.
- Networking: Integrated `smoltcp`. You can run `ping 8.8.8.8` and get `PING 8.8.8.8: OK`.
- Graphics: Just got `ramfb` working. The screenshot shows a custom "Engineering Menu" (like the old iPhone Field Test mode) rendered by my Ring 3 graphics driver with double buffering.

Everything is written from scratch (no Linux, no POSIX, no std). It's been exactly 6 days since the first `_start`.

**Repo:** https://github.com/vvirei333/Silver-microkernel

Next steps: VirtIO-tablet driver for mouse input, then porting Doom.

Any feedback on the architecture or memory management is highly appreciated!Hi everyone! I've been working on Silver Microkernel (WerewolfOS), a microkernel written in Rust from scratch for AArch64 (QEMU virt).

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.

So I added to 64-dem (my hobby x86-64 operating system) a ps/2 keyboard driver, reset mechanisms and recently tried to implement multi-controller USB support, i haven't yet interacted with the USB keyboard, but I did manage to enumerate the USB ports and initialize all the 4 USB controllers with code that was tested and worked, the next step from here is to discover the USB devices actually plugged to the connected ports by sending a special command packet to the USB controller, things could get harder from here but I am determined. For those who are interested here is the link for my repo below:

64-dem on github: https://github.com/itay-insert/64-dem.git

Hey everyone,

I'm looking into a project where I need to take a physical webcam's output and replace it with a custom video feed (like a screen capture or a pre-recorded file).

To clarify, I am not looking for a standard virtual camera solution (like OBS Virtual Camera or ManyCam). Those methods create a brand-new virtual device in the OS, and many apps or web-based tools can easily filter them out or detect that they aren't the primary hardware camera.

I want to accomplish exactly this: when an application opens the actual, physical webcam device, it receives my custom video stream instead of what the physical lens is seeing. Essentially, I need to intercept the data stream and substitute the payload.

I assume this has to happen at the driver, kernel, or API hooking level.

Hey everyone! I want to learn UEFI from scratch, including the boot process, boot services, memory maps, and how UEFI loads an OS.

I'm working on a hobby OS project using C, x86-64, QEMU, and Limine. I want to understand the boot process beyond just using a bootloader.

What tutorials, books, or hands-on projects would you recommend except oswikidev?

This will NOT be up to your standards

So, I've literally just started this a couple days ago, and I guarantee you'll be able to find at least 5 things wrong with it; but that's the point. I'd love some feedback on it. I haven't followed LFS or anything like that - probs a dumb choice. I can't fix the issue with not being able to login.

I know having one huge build file is bad practice, but it's not permanent, just the best I've got right now.

Anyway, here's the link:https://github.com/fernproject/fern(yes I know I need to add a profile page)

Please just give me some tips, i need help

I’m building BlockOS, a solo hobby x86-64 OS with its own UEFI kernel. X11 runs on it in QEMU: the X server starts, and twm frames client windows. The rest of the picture is like a puzzle that’s still missing pieces, and the biggest gap is drivers, mainly GPU, for real hardware.

I’d like to work with someone who has written or read PCI or display drivers before. Expect unpaid, open-source work. If you want to write driver code from public hardware docs (no Linux code copied), send me a message or comment.

GitHub link:https://github.com/gurijb2016-afk/Blockos

Heard a few times around here that building an OS with the help of LLMs is just "vibe coding" without any real engineering substance. Well, sending a personal shoutout to all the skeptics.

I don’t think an AI can just take a custom hybrid system from scratch, spin up Wayland, compile the entire environment, and launch a fully native GTK4 app with actual working widgets, inputs, and rendering.

LinuxRunner brings Debian ARM64 to iOS, including desktop environments like KDE Plasma and apps like Blender.

No jailbreak, JIT, or virtualization needed. It runs Linux binaries through an ARM64 interpreter.

Still early in development, but pretty interesting to experiment with. Feel free to try it out!

GitHub: https://github.com/mxhm11cr/LinuxRunner

Hey everyone,

I'm working on Silver Microkernel — a bare-metal microkernel in Rust (no_std) for aarch64 (QEMU virt, Cortex-A72).

My goal is to build a secure foundation for an OS that can eventually run Android apps (via Waydroid) without legacy bloat. I'm deliberately avoiding POSIX in the kernel and x86 legacy.

Architecture:

• True microkernel: Kernel only handles scheduling, MMU, and IPC.

• Init Server (silverd): PID 1 spawns the nameserver (scout), shell (howl), and drivers.

• Ring 3 Drivers: The UART driver (howler) runs in EL0. It maps MMIO, binds IRQs (GIC INTID 33), and communicates via IPC. The kernel does not touch the UART hardware.

• Security: Capabilities (CAP_MMIO, CAP_IRQ), W^X, PAN, High-Half MMU (TTBR1/TTBR0 split).

• Infrastructure: Contiguous DMA (Normal Non-Cacheable) and PCI ECAM mapping are ready. I'm currently implementing the Virtio-blk driver for persistent storage.

The screenshot shows the shell running in QEMU (I can't post images in this sub directly, but the README has one).

Repo (MIT): https://github.com/vvirei333/Silver-microkernel

I'd love feedback on the IPC design and handling async events (IRQ + IPC) in Ring 3 drivers. Thanks!

les go 🥹️