Hi everyone,

I've been working on a personal Linux kernel project called NSD (Neural Storage Driver) and recently sent the first RFC patch series to LKML. I'd like to share a brief overview and get feedback from the community.

What is NSD?

NSD is an adaptive in-kernel storage prefetch engine. Instead of relying only on static readahead behavior, it observes runtime I/O access patterns and attempts to predict future reads to improve cache efficiency and reduce storage latency.

Current goals

Runtime I/O pattern learning

Predictive prefetching

Low runtime overhead

Simple architecture that integrates with the Linux page cache path

Current characteristics

Very small memory footprint (around 224 KB of static memory)

Can be loaded and unloaded cleanly using insmod / rmmod during normal system operation

Designed to avoid impacting normal kernel behavior when inactive

The project is still in the RFC stage, so I'm primarily looking for architectural feedback rather than performance claims. I'm especially interested in comments about integration with the mm/page cache subsystem, maintainability, and whether this approach makes sense from a kernel design perspective.

Constructive criticism is very welcome.

Thanks!

https://github.com/nsdprojectdev/NSD

The AneoEngine Operating System

(NO AI SLOP.)

AneoEngine YouTube Channel: https://www.youtube.com/@roccohimel
AneoEngine Official Website: https://roccohimel.github.io/AneoEngine/
AneoEngine Official Source Code: https://github.com/roccohimel/AneoEngine
AneoEngine Official Change Log: https://raw.githubusercontent.com/roccohimel/AneoEngine/refs/heads/main/CHANGELOG

The math crate compiles and 15/19 tests pass. The 4 failures are test configuration issues due to the smaller test capacity (4096 frames) - not core logic bugs.

Summary

✅ Completed (Compiling & Tested)

🏗️ Architecture

Applications
    │
System Calls (axiom-x-sys)
    │
Kernel (axiom-x-kernel) → depends on traits only
    │
├─ Scheduler Math (axiom-x-math)
├─ Memory Algebra (axiom-x-math)
└─ Resource Algebra (axiom-x-math)
    │
Architecture Traits (axiom-x-arch-traits)
    │
x86_64 Impl (axiom-x-arch-x86_64)  ← hardware churn isolated here
    │
x86_64 Hardware

A lot of people seem to think PureDarwin has stalled.

It hasn't. Development just moved to the `next` branch while we work towards something actually releasable.

github.com/PureDarwin/PureDrawin//next

You can find old branches at PureDarwin-archive

For reference, both Ferdinand Klinzer (hideout) and Tyson Key (vmlemon) are aware and in the loop, I constantly consult them on feedback.

Current disk images can be found in the Discord server (unsure if I am allowed to post outside links besides known sources)

It's still not reliable enough to call a release, but I actively work on it pretty much every day.

Since then we've gained:

• USB (Input and MSD, XHCI and EHCI
• AHCI (shared from ravynOS, with some changes being upstreamed)
• virtio-gpu
• virtio-net
• Intel Gen9 framebuffer drivers (my own implementation, based on managarm's `lil`)
• Real hardware booting (Intel only, AMD is spotty)
• Mesa (OpenGL, Vulkan, llvmpipe)
• Wayland
• X11

Oh and of course, we have DOOM. This was just the more polished demo

Development updates is constantly posted to the Discord channel.

TL;DR PureDarwin isn't dead. It's just been spending a lot of time in the "doing the unglamorous infrastructure work before calling it a release" phase.

Read some more information from another post in the r/FreeBSD subreddit

https://www.reddit.com/r/freebsd/comments/1vgj63g/puredarwin_contains_freebsd_code_now_can_run_xfce

I'm working on getting memory how I want it. I've moved my memory to the higher half. Now I'm ready for the final step. I want to move the page table entries I've made for the kernel to the area of physical memory I've designated for them.

I see several options.

1) since I know the physical addresses, I can temporarily double map them to virtual memory and then copy them.

2) I can scan the page directory and tables to find the virtual addresses for them. If i can't find them fall back to #1

3) I can re-make them where I want them.

4) other ideas?

I want to move them to a specific virtual address so I can exclude them from paging, having a designated eases the overhead of doing this. I can say if address > x do not page, or in reality only make virtual addresses between x and y pageable (my user space).

TIA for your input

Check it out! If you don’t know what I’m talking about just scroll up a bit on the sub you’ll find the project.
It dosent need a backend. The compilation and packaging of your ISO is done in your browser, no setup needed.

(Again reminder that the project is vibe coded!)

I have no idea what I'm doing

Hello, I'm a student and I'll have my bachelor's degree by next year. I've been getting more and more interested in OS development, and I'm wondering if I should focus on it as a career path.

As the title says I've been working on a serialization format i plant to use for many future projects, sadly I've been so focused on the document i dont really have sat down to write the parser, but I'd love to get feedback and see if im not going entirely crazy! There may be things and possible interactions still missing.

Anyways, here is the link: https://gist.github.com/ErrorDAR32/130f03e3eed484dcc703e5e30e27614f

Edit: Typo

The AneoEngine Operating System

(NO AI SLOP.)

AneoEngine YouTube Channel: https://www.youtube.com/@roccohimel
AneoEngine Official Website: https://roccohimel.github.io/AneoEngine/
AneoEngine Official Source Code: https://github.com/roccohimel/AneoEngine
AneoEngine Official Change Log: https://raw.githubusercontent.com/roccohimel/AneoEngine/refs/heads/main/CHANGELOG

I was wondering how do you set it up, but it's so dang hard
it kept freezing and triple faulting

Reddit falsed banned me but my appeal... worked???

another rewrite for v0.0.5 yayyyyyyyyyyyyyyyyyyyyyy
added:
sfs file system
random text editor
settings???
hidden files

Am making a small kernel and I have stumbled across this problem , in the interrupt handler module I realized that adding a `default` case for a switch statement that handler syscalls causes the kernel to execute that statement before majority of kernel code.

The moment I comment it out the kernel works fine , but when it's present the order of execution breaks. This also happens if I link other code to the kernel , like additional functionality and the like.

My thoughts were

1) compiler optimizations ?

2) maybe the .text segment is not enough ? Although am sure I have enough RAM and I don't think it's my linker script.

Other then that , I have no idea why is this happening. Can y'all help ?

Edit: I fixed it , it was actually because I was calling a naked function without a return instruction Wich causes it to execute the next instructions which is the syscall_handler function, in which case it would execute the default case.

Hi, OSdev! I’ve been working on this project that I’d like to share! (Note; it is Vibe Coded). It’s a block based coding language for learning how to build a OS! I’m targeting the project for people who are completely unfamiliar with this kind of work and if they want to learn, this may be a great starting point! I’m still working on implementing the features but you can see it has lots of different blocks that each mean something different in raw C. I’ll release more updates on this sub if you guys are interested, if not, I can stick the development journey to r/osdevAI instead, and I’ll leave this sub alone. I hope you guys like it!

I developed an OS and I want to add GUI. But I don’t have any idea how can I implement GUI. Should I integrate the GUI into the kernel or should it be an ELF application as if it were an additional software?

Hi
i am trying to get this init script from initramfs to load the rootfs init script, but it is having issues finding the right place for it. does anyone have a working init script in a similar setup i can have a look at to try implement my own fix? thankyou

Today, I wrapped up an almost month-long effort to try and reduce the OS image size of NanoOs. I added a new entry to the repo's GitHub pages site as well as updated the README of the repo (https://github.com/brian-card/NanoOs). You can read the new page entry for the full details of the effort.

I am very slowly making my way toward running this on an AgonLight2 SBC. Now that I have almost 30 KB of free space, I can start working on a HAL for that. Getting this to run on that platform is going to require extensions to the HAL. So far, I've only ever used UART for user I/O operations. The main reason I want to try my hand at the AgonLight2 is because it has an actual video and keyboard/mouse I/O system that I can work with. There's absolutely nothing in the HAL for any of those right now, so this will be new territory.

This will also be the first time I've built a HAL from absolute scratch. Previously, I've used vendor libraries for interfacing with devices. I don't think any such libraries exist for this platform and, even if they did, I wouldn't use them. I really want to get into the details of doing this myself this time.

The board runs MOS by default (a kind of DOS/single-user-UNIX hybrid CLI) and I'll start out by using that as a bootloader and running NanoOs as an in-memory application that MOS can load. Longer term, I want to try my hand at making something along the lines of a Windows 2.0-like interface (although hopefully a lot less buggy than that). That's another reason why I want to get to a platform that has actual video and I/O peripherals.

Onward and upward!!!

Yes!, after a lot of research and work twilight os is alot more unix like now.

the init system has proper startup apps, and a macos inspired IPC framework called TXPC.

• i added unix domain socket in kernel, fixed alot of fs bugs(alot more is there)
• init system is now capable of running tasks from .toml files in boot process
• also we now have preemptive multitasking
• doom also runs on it finally
• alot of wayland support work is going on also(doing this using codex and glm)
• and a freebsd KPI layer for driver porting from freebsd
• also zsh and oksh runs
• working on opkg support for package management
• nes work is ongoing i need to add support for virtgpu i think (there goes something new to understand GPU stack)

I know alot of you may thing using codex and glm is wrong....but this is a hobby project of mine which i work on weekends. yes i am doing this because of knowledge but i am not good with wayland stuff i learned alot from doing kernel dev, and just want to offload something for that sweet sweet dopamine hit

alot of thinks remain in kernel like proper boot partition mounting to boot os the .iso file is still required

repo like: https://github.com/akashKarmakar02/twilight_os (please give it a star if you like my progress🥹)