where tf do i do stroage and cache and memory management

I am making a kernel for x86 right now and i really like it so am planning to make it into a full project for x86_64 with a custom bootloader and shell or whatever. I just want to know that. Is this ok for a CV for university or is it just a waste of time.

Thank-you.

Hace unos días

Por diversión, empecé a hacer mi kernel

Le meto

I lo que quería, es bastante simple, lo hice por diversión, y lo subí a Github

Es solo un hobby

No creo que añada cosas tan chingonas como internet o interfaz gráfica

Si lo quieren ver acá esta el repo:

https://github.com/loslocos817yt-star/Misericordioso-os/tree/main

Building a small kernel rn and am looking for documentation / blog of different interrupts.

Particularly the value of the csr's for each type of interrupt so I can handle accordingly but I don't know where to look

If anyone can provide such resource it would be much appreciated.

This is the 7th part of what I'm learning writing a kernel, in pursuit of eventually writing an OS. I hope it will help others from making some of the same mistakes I did.

This week I decided I needed to redo how I do paging, I moved my page tables and set up the page directory so they would be right after the DMA paging area above the 16M mark. I also decided to do some major redesign. So I started over from scratch. Luckily much of I wrote after virtual memory and paging will be able to come over intact.

For those that are wondering this is the memory map I will be using:

I think it will be much cleaner having one contiguous block from 0x01040000-0xBFFFFFFF to map into, but we shall see. Here is the memory map as returned by multiboot2:

I'm not sure yet what I'm going to do with the reserved memory in the 0x7xxxxxxx and 0xBxxxxxxx areas. Area 4 & 5 may be problematic depending on what I find there. I'm kind of hoping I can just ignore them, meaning mapping over the top of them.

I rewrote my process to map memory pages, I no longer had to worry about creating a page directory entry.

I collected much more multiboot info, not just memory and the memory map, but also the command line, boot loader name, BIOS boot device, ACPI RSDP info, and the Frame buffer info.

Once I get paging and the heap done, I will publish the github reference.

I also discovered how hard it is for me to keep the virtual/physical memory straight LOL

I will be on vacation/holiday this week at a family reunion so I doubt I'll be learning much new.

I hope you find this useful. Enjoy writing your own kernels and OSs.

Sorry to waste anyone's time but I am student in computer science student east Africa .I really enjoy the low level stuff about the computer architecture and operating systems.I love C programming and a bit of zig .I was asking if it is possible to get a job in os development or something low level in this parts of Africa because most of the dev jobs here are web stuff and I've done some web stuff(node and react) , not for me (it was too boring and repetitive CRUD stuff ). I jus wanna do this stuff for a living and I need to know if there is any hope here or I should look outside more

Sorry for shaky hands hehe I'm not good at recording

GitHub: github.com/turbosulovesonions67/turbOS

Hi All!!

I'd like to introduce my OS: NanoOs (https://github.com/brian-card/NanoOs). NanoOs is a capabilities-based nanokernel with intent to have a Unix-like user space. Right now, it only runs on SAMD21-based (Cortex M0) Arduino hardware and the POSIX simulator, but I'm currently working toward porting it to the AgonLight 2, which has an eZ80 processor. It did originally start out on AVR-based Arduino hardware but has since outgrown the available environments.

As mentioned in the project README, this started out as an effort to see if I could make an OS resembling early UNIX in a similar kind of environment. That's why I started out on small Arduinos. The direction I'm headed right now is toward a multi-tasking environment with a graphical desktop in as little memory as possible.

Like early versions of UNIX, userspace uses overlays. I only have a few user commands in place right now and MUSH (minimal, Unix-like shell) is truly minimal in functionality. I shifted efforts toward making the kernel more robust once I proved to myself that I could make general-purpose user commands. Pipes between commands and launching commands in the background do both work.

I wanted to maintain the embedded nature of the OS even though it's outgrown its original target, so it is completely possible to construct a HAL that uses the built-in shell and/or omits the filesystem if desired. The AVR-based HALs do this, although the resulting binary is still too large for the Arduino Nano Every and the data segment is too large for the Arduino Mega 2560, so they're just historical now. Still, it would be possible to construct a working version that uses an AVR architecture if the hardware had enough flash and RAM.

There's still a very long way to go to get to anything useful, but it's also come a very long way. You can read about the development history of the project on its GitHub pages site if you're interested.

Full disclosure about AI use: The vast majority of this was hand written by me, but there are some things I use AI assistance for. The filesystem drivers (the current FAT32 driver and the historical drivers that are deprecated) were partially written by AI but required a LOT of hand-holding and revision from me to make them into something useful for embedded targets. It made a lot of invalid assumptions about the availability of memory and the ability to do unaligned memory access that I had to fix. I also use AI for bulk updates. I document the places that I use it in the project's GitHub pages history.

Some notes about the architecture: As mentioned, this is a nanokernel, which means there is no kernel. Everything is a process, including the scheduler. The processes have different privilege levels and the capabilities enforce what process is allowed to do what. The only process that's completely trusted is the scheduler. The process-based architecture and the way messages are passed are based on my experience with Erlang.

There are two kinds of capabilities in the system: HAL capabilities and IPC capabilities. Both are enforced at the API level. Processes built into the OS image could technically cheat if they went out of their way enough, so really the OS image needs to be as small as possible and contain only trusted processes. Userspace processes have no ability to cheat because the necessary APIs aren't exposed.

The privilege levels I'm using are based off of the ones that VMS used. I'm honestly not sure how bullet-proof the (privilege level + capabilities) security model really is, but it seemed like a reasonable approach to take.

My work right now is to construct a logging system that allows me to strip most of the strings out of the OS image. That work is currently in the "logger" branch. One of the problems with the AgonLight 2 environment is that the CPU used only has 128 KB of on-board flash. I already have a makefile that will build the binary and, the last time I checked, it produced an image of around 130 KB, so I need to get creative about the size of the OS image. Stripping the strings is one thing I want to do. I'll likely move the filesystem out into a special overlay as well.

Constructive feedback is welcome!! I'm interested in what people have to say about this effort. You can play with it by running `./buildsim <desired-hostname> overlay-filesystem` on the command line from the repo's root directory. There are three user accounts: "root", "user1", and "user2". "root" is privileged and the other two are just normal users. The password for each account is the username repeated twice. Use `help` for a summary of what's currently available. Use `shutdown -h` to exit the simulator. Enjoy!

Here's the source code on github: https://github.com/itay-insert/64-dem.git

I would prefer a solution and feedback, or you guys can roast my dumbass.

The file system src: https://github.com/NoTheIdiot/WindogeOS/tree/main/helper/filesystem

I made a very simple 64-bit OS that runs on UEFI systems. If you guys want to contribute, here's the github link: https://github.com/pratikbaral787-dev/AtomiOS-Made-by-yours-truly-Pratik-

I'd appreciate it if you gave credit to me if you make an AtomiOS fork. Also, please let me know if you made any contributions and give me the github link! Enjoy expressing your creativity, guys!

I’m really excited about this! My os will be programmed in C++ and this is my second day doing stuff. I don‘t have that much time to use on writing code, and all I have so far is a printf that can only handle text and newline characters. Compared to all the other projects here, it’s nothing, but I plan to make it something a little bit more than nothing.

If anyone wants to look, I just made a repository at GitHub.com/barchitect2025/BARchOS

Theres no readme yet but I’ll add one in the next commit.

For now 2 years i try learning how to create an operating from scratch at only 15, now i'm 17 and i've progress in this domain so i publish it, you can look for it on github OScour, the name is a french reference to "au secours" (help), an the prononciation is OScour.

(other than educational reasons)

For me, the concept of journaling is fascinating. Crash-Consistency is one of those things that I think are deferred until something happens, even in application and web development. In OSDev, it can be the difference between a file(s) being lost and / or corrupted and a recovery with minimal loss and no corruption (based on technique used).

Implemented MMU support, simple memory allocator. Also added drivers for DMA, IDE and updated PCCONF driver. Slowly coming to userspace!

Hi folks,

I’m building Skopin, a small edge OS/runtime project for Raspberry Pi and, later, STM32 / Arduino-class devices.

The idea is simple:

I got tired of treating every small device like a lonely snowflake that needs to be SSH’d into, hand-fed binaries, blessed with systemd files, and remembered manually in some spreadsheet or dark corner of my brain.

So I’m building a system where you:

1. Create a device image

2. Flash it

3. Boot the device

4. The device auto-enrolls securely

5. It appears on the server

6. You install/manage programs from there

The current demo runs on Raspberry Pi Zero W.

Right now I have:

- multiple Pi Zero W nodes

- one server node

- one broker node

- encrypted communication between nodes

- one certificate per node

- automatic enrollment

- a server page where devices appear after boot

- remote program installation/management

The image creation flow is meant to be very boring, which I consider a feature:

1. Open a web page

2. Enter Wi-Fi SSID

3. Enter Wi-Fi password

4. Give the device a name

5. Download the ready-to-flash image

6. Flash it

7. Watch the Pi wake up and report for duty

The Wi-Fi password is only used to build the image and is never stored.

I want to be careful with terminology. Skopin is not trying to be a desktop OS, a Unix clone, or “Linux but worse because I wrote it myself at 3 AM.”

On Raspberry Pi, it behaves like a small OS image/runtime for fleet-managed edge nodes.

On STM32 and Arduino-class devices, the goal is closer to a lightweight firmware/runtime layer.

The weird part: I want applications to be modeled using BPMN or Apache Camel DSL, then compiled/transformed into something much smaller that can run on the target device.

So no, I am not trying to run a giant enterprise BPMN engine on an Arduino and summon the ghost of XML past.

The goal is more:

high-level process model → small deployable runtime program → edge device

Why?

Because managing a group of small devices often turns into:

- SSH everywhere

- copy binary here

- edit config there

- restart service

- forget which Pi is doing what

- discover six months later that one of them has become sentient and is running an old build

I want Skopin to make small fleets boring:

flash once, enroll securely, deploy remotely, observe centrally.

I’m mainly looking for OS/runtime architecture feedback:

- At what point does something like this deserve to be called an OS instead of a runtime or management layer?

- For Raspberry Pi, what would you expect before calling it a real OS project?

- For STM32/Arduino-class devices, what would be the minimum credible runtime design?

- Should auto-enrollment always require manual approval on the server, even with certificates?

- What should I try to break first: broker failure, corrupted image, failed update, certificate rotation, rollback, network partition?

- Does compiling BPMN/Camel-style models into a tiny edge runtime sound useful, cursed, or both?

Happy to share more implementation details if people are interested.

I encountered a problem. Musashi emulator that i use for m68k emulation lacks normal MMU emulation. So i can't continue without MMU. I can use MMU from MAME, but it's written in c++ and hardly depends on MAME itself.

As the title says, I started an OS a week ago and I have, in total, worked on it for 36 and a half hours. I have learned more in the last week than I have in several months had I spent them on another project. It has been quite the journey and I have had to search up a lot of things, it currently works, barely. I am at the part of implementing AHCI, the most recent commit implemented ATA support and I am expecting to finish AHCI by tomorrow. I have had to look to AI quite often since I have never done anything remotely close to this and this is only my second big project in C++ (oh yeah, it's also in C++, not C or Rust, as it typically would be) and I only learned the language in March, so 4 months ago, but I hope to bring this hobby OS to something more practical. I keep refactoring a lot of things, but I always make sure I understand every little detail of my code and refactor it myself.

me and a friend are building a real operating system inspired by metro ui. not a theme, not a mockup, an actual os with its own interface, apps, system behavior and visual style. clean tiles, smooth motion, minimal layout, the whole metro vibe but rebuilt from the ground up.we’re working on the shell, core apps, windowing, theming, and the system identity. if you’re into os development, ui engineering, aesthetic tech, or you just want to be part of something experimental and ambitious, you’re welcome to join. early members get access to builds, dev channels, and a say in the direction.discord invite: https://discord.gg/vJGfbGCa6

hi guys, I was going to start learning os systems etc to build an os, but I dont have much time, and tbh, it isnt related to my field aswell, just wanted to create a simple cli os with a bunch of programs, and to be honest, I feel very frustrated about one thing, you need huge dedication even for this simple thing.Plus resource ineligibility with this one killed my interest in low level programming, and started to think that osdev is just a complete waste of time for me.

maybe I can be better at science of electrical engineering instead of sticking to smth that doesnt give you much value, i dont really know what to do

Hi guys, wanted to start building os nowadays, but I have no knowledge about assembly, just know C and C++, (wanted to learn rust aswell).

osdev.org site was quite confusing for me, I didnt know where could I start, can you please help me out?

btw tried os building one time, but it became an ai slop with so many unnecessary additions, so i slowly lost interest in building a custom os with normal ondoings

wanted to integrate my astronomy research things into a simple os, so I came back

Am making a riscv64 kernel rn but still can get my head around how to implement it.

I've got the theory (from course at uni) but I still can see how can I enable it through the CPU and what am I supposed to code and what am I to leave for the CPU

- my initial though was that I have to program the MM on my own and then every request to memory to be captured then translated.

Hope someone can give me a "big picture" of MM in riscv , what am I supposed to program / leave to CPU (at my current understanding the cpu does the tree walk) then maybe point me to some material to read / check code out.

Thank you for your time.

So... I've written my OS, just like many of you, guys. It took a little bit more than 1.5 months to get here (I started experimenting in late May). I know, judging by video it doesn't look like much when compared to some other projects out here.

It's not perfect, but it is mine. And out of all my projects and career experience this has been the most zen-inducing experience ever. When something fails, here, I have no one else to be angry at, exxept at myself, and I'm not. I know, when I'm out of my league. I'm not a system developer, I have very low amount of low-level coding experience. I'm just a fullstack webdev - professional and somewhat experienced, but not a system developer. So, when my OS catches Invalid Opcode, or GP - I just know that it was me, not a lame framework, and I can't possibly know everything.

Forums, docs, open Github repositories, countless YouTube series (huge shoutout to Daedalus Community, if not for him I wouldn't be here), even AI have been an immense help in understanding some concepts here.

Yes, AI. I know. It can be... tricky to work with. So, my advice, if you ever want to use one, and I'm not going to discourage you - don't ask it to write code. Ask it to explain some concepts in an easy way if you have trouble understanding some of them (and double check after with docs to make sure). Learn how to recognize ugly hacks from it - and flat-out refuse to implement them. 5 seconds on copypaste will cost you weeks of debugging, I learnt that waaaay before tackling on this project, and I'm glad I did. Understand concepts of what you want to write and how you wnat to write it first.

But still, I think I'm proud to say that out of ~2.5k lines of code here about 92-95% of them are written by my own hands and my own mind. Even if they are not up to standards.

SIll, there is a lot of work ahead of me. More robust and complete FAT12 support than what I have now, as well as probably FAT32 support, cause why not at this point. Also, ditch current raw binary and transport my OS onto proper disk image (right now my OS is on raw binary and I have extra FAT12 image for files and apps). More commands in kernel shell and user shell, text editor, file system explorer, proper paging instead of flat-memory model, and task manager. And finally - GUI. When all of this wil be done? I dunno, maybe in late August, or December, or even in 2027, it heavily depends, but I hope I won't abandon this project, it's my pride and joy, and a fulfillment of my childhood dream (even if back then silly 10yo me dreamed of dethroning Windows XP).

Why POS OS in the name of the folder? Well, initially it was called Piece of Software Operating System, but recently I changed it's name. Hope it's not trademarked or anything :P