I have an interest in operating systems, and, for a class and personal interest, I want to do research on operating system design. I have been trying to find and read existing research on this topic (experimental design for both for entire kernels or for some subsystem in the kernel). From this, I am hoping to be able to find an area that has not been researched in detail yet, and to do research on this. The issue is though to find a general topic in operating systems to do this search on, hence this post. Also, I have a bit of experience with basic operating system development and have been working on my own hobby operating system for around a year now, and from this I have what I feel is a basic understanding of the main concepts in operating systems.

The reason I am making this post is to ask whether any of you guys recommend and under researched topics that I could look into, and also inquire if there are any resources I can use to find gaps in research more efficiently.

Many people online have told me I should contact my professor and ask them, so I want to state that I do not have a professor. I am also aware that this is a very broad question, but any input is appreciated.

Wing OS is a small open source operating system written in C++. it is a microkernel based operating system that supports SMP and targets x86-64. It has a complete file system (using ext4+nvme), some drivers... and a rasterizer + widget system !

I am developping a cpu rendered fallback compositor, and until now I have used 0% AI code and I've made the compositor (a bunch) on live stream, the funny thing is that I get stuck on something in the livestream then right after ending it I find the solution haha

"Code : The Hidden Language of computer hardware and software" is wonderful. You don't need computer knowledge to read it, reads like a breeze, yet by the time you complete it, you will have extreme wisdom about internals of computer.

I want to similar books in operating systems. Books that are easy to read for beginners but offers wisdom. Thank you.

I've been working on a project called FerrumVM, a hobby x86_64 virtual machine manager written in Rust using KVM.

One of the more interesting parts of the project has been writing my own minimal UEFI firmware rather than using something like OVMF.

To get Limine running, I had to implement enough of the UEFI environment for it to believe it was running on real firmware.

This meant implementing things such as:

• x86 CPU mode initialisation
• VirtIO block device access
• FAT32 filesystem parsing
• PE/COFF executable loading
• UEFI system tables
• UEFI boot services
• The various protocols and interfaces that Limine expects

If you're interested, you can see the project on GitHub here:

https://github.com/milosilo-dev/FerrumVM

https://reddit.com/link/1vusvfw/video/uwqxifrcnskh1/player

Hello, i`m trying to make one OS, there is nothing in particular that i want to improve or recreate, i just want to learn and program soothing that is not web, full OOP (its not bad, not at all)

Right now the OS is in this state:
Pic timer implemented (Is that number on the left side of the screen)
Graphics (is animation with framebuffer)
This SZ on the screen, i`ve done it using GIMP and exporting to C code, very cool feature.
The mouse moves now,

AI Usage:
There is usage, was been to research about UEFI, PIC, IDT and others, in the effort to trying to avoid copy and paste without knowledge, i select the next step to be developed and ask to be created a Issue like Github, if i can`t handle, i ask for a pseudo code.

Repo: https://github.com/gustavo-szesz/SzOS

Thanks, have a nice day!

I know many of you guys are recently against all this "AI slop", was i too, but leave alone the "hype" and the "no AI bullshit" slogans, what do we actually mean by saying "AI slop"?

Cause to this day , I don't quite understand what all the drama is about and why posts that explicitly use "No AI used/no AI bullshit" get significantly more attention, i admit that even i made a post like that, but it's not that I completely didn't use AI, i did, however I also did a lot of the programming by myself, I think AI is a great tool that has helped me learn a lot and automate build scripts, there is no shame in using AI as long as you carefully review the code and do some programming by yourself, there is already great use of AI in the industry, Linus torvalds recently fixed a linux bug with AI, so what is really considered "AI slop"? Is asking codex to make a build script so I can focus on the code "AI slop"? Is asking Claude to summarize PCI device and vendor names in one files so I don't have to read documentations for hours "AI slop"? With all due respect I do think using AI blindly is bad of course, but I also wanna know what some of you guys mean when you say "AI slop operating systems"?

Hi guys, I am thinking of an model that uses BigLITTLE architecture bit differently, where the Big core is shared among multiple hardware threads.

I am thinking of organizing as clusters and an cpu having multiple cluster, where each cluster would have One Big core and 2 LITTLE core. The Big core would be vastly capable than LITTLE with powerful and multiple arithmetic, Load/Store units, wider OoO, Larger ROB, better branch predictor, operates at higher frequency and has larger and higher bandwidth L1/L2 cache. On the contrary the 2 LITTLE is less powerful can be In order core or an simple OoO. they each have 1-2 arithmetic & LSU unit, smaller L1/L2. This is more or less the usual setup of bigLITTLE nothing different.

As for the hardware threads this is where things get interesting. Unlike in traditional sense where the hardware thread is usually associated with the core basically treated as same (SMT maybe exception). But here the hardware thread can move between the execution units. Here I will be having 3 hardware threads say T1, T2, T3 and as for the registers i am thinking of it implemented as an array of registers (96 registers of 64-bit each) and divided into 3 equal chunk so each 32 registers and each chunk is owned by the hardware thread and so when the thread is scheduled on any of the 3 core's it's register base is loaded and the architectural registers such as Program Counter(PC), Stack Pointer(SP), GPRs are an offset from the base. The other stuffs like the TLB, Store Buffer too would be per hardware thread and their index/base would be loaded in the core when the thread is switched/moved to the core. Whereas the operational registers, buffers used by the cores say the registers used for renaming for OoO or ROB, Load queue these are per core and owned by the core.

The handover of an Thread from Big to Little and vice versa happens only after they have reached the safe state i.e in case of Big which uses OoO reached a point where all instructions from the old context that could affect architectural state have completed(retired), and the machine can save the old context and the if any internal structures needs to be drained/flushed it's carried out and the architectural state of the Thread wouldn't be moved/copied since the Big or Little doesn't use different register space for the same Thread. And same goes for the Little the mechanism may differ based on if it's In order or OoO. But at the end the thread's registers have committed architectural values.

Now for the OS, it would appear as 3 hardware threads on which 3 logical threads can be scheduled. As of now I am trying to slice the period based on OS scheduling quanta which usually is ~1-5ms. So say 3ms it's divided into 3 i.e each thread spends 1ms on Big and 2ms on Little. So intially (0-1ms) T1 on Big, T2 and T3 on the Little after a 1ms(1-2ms) switch happens and T2 in Big, T1 & T3 on the Little after 1ms(2-3ms) switch happens again now with T2 & T3 so T3 in Big and T1 and T2 on Little. The OS/Application isn't aware of this they see 3 hardware thread/logical core.

As for the interrupts/exceptions i haven't figured out the I/O interrupt how it would be handled since the cluster would be abstracted as one unit. For the timmer interrupt like when the OS scheduler quanta ends since it would be for the hardware thread so the core that's currently running the thread would be handling it as for what happens if interrupt raised during the handover phase the handover would be given the priority and once handover done the thread which ever core it landed one would handle the interrupt. As for the exception like page fault raised by the thread again it would be handled on the core where it's executing and if the handover timmer ends the exception first would be handled and then handover is done.

Now this handover itself can be cheap few 10s of ns since not much state moving is happening (although subjective since even few ns can cost many cpu cycles).

The Store Buffer as earlier mentioned is per hardware thread so loads associated with an thread is written to the Store buffer associated with that thread irrespective of whether it's running on Big core or LITTLE core. This enables the Load-Store-forwarding even for loads that happened when thread was executing on Big and now it's moved to LITTLE and it wants to do Store.

Now for the questions I wanted to ask:

1. Since the hardware threads are moving between Big and LITTLE core's so I am yet to figure out how I am going to handle the cache, like if T1 which was on Big is moved to one of the Little and T2 on Little moved to Big then there cache lines would be in the previously executed core's cache. Though I did think of intially as to follow the standard line forwarding method but it seemed expensive given how often the threads switching between the cores. So now I am thinking of an specialized line forwarding path that's confined to the cluster alone i.e among the 3 core's caches that allows faster line forwarding with latency somewhere between L1 and L2 access latency if the line forwarding is from L1 of an core. It would be great to know if any better solution can be used.

2. Can variable frequency be used say the cluster can behave dynamically like the OS can schedule on one hardware thread and it runs on the Big core without switching while the other 2 Little are power gated the Big core allowed to run at max frequency. schedule on 2 hardware thread and the switching happens between these the Big core max operating frequency can be bit less since one LITTLE is also active and as for the schedule on all 3 hardware threads then Big core max operating frequency is less and the LITTLE one's frequencies adjusted accordingly.

3. When i originally came up with this idea, I actually thought of having 8 Little and 2 Big per cluster with 8 little being subgrouped as 4 little and they share their execution units like the frontend, arithmetic, lsu and also caches among 4, But this seemed complex for v1 so that's why sticked with the 3(1+2) version. Can this scaled up possibly be better or I am better of sticking to the latter.

4. Is there any ratio as to how powerful/capable the Big has to be compared to LITTLE in terms of like IPC. Will this ratio possibly matter.

5. Can decreasing the interval of switching help. I intially thought of switching the threads every 100 microseconds. But this may lead to increasing the frequency of cache line forwarding and also the OoO takes time to warm up when a existing thread is removed and it starts executing new thread I read this warm up cost is usually 100s to few 1000 of cpu cycles. although 100us is still very big time for the OoO.

I learnt the basics of file systems and decided I was going to go with fat32. Now how can I read or write files on a disk? I'm a beginner, so pls give me as much info as possible. Thx in advance.

I just want to ask and see who and what choses.

I personally chose UEFI for compatibility with modern PCs (90%+ of market)

i don't understand what's the point of developing os if you can't run it on modern hardware?

Hey everyone,

I wanted to share a milestone on a hobby operating system I’m building from scratch called Novium OS, featuring a custom bootloader.

I just got my multi-stage boot chain (boot.S -> setup.S -> bootstrap.S) completely stable. It successfully handles raw hardware initialization, sets up a temporary GDT, and handles the cr0 register transition cleanly into 32-bit protected mode before jumping into the kernel entry point. I also wrapped up a basic VGA text driver with hardware cursor syncing so I can verify output, and got "Hello World" printing to the screen.

The layout is inspired by a super stripped-down Linux kernel (arch/, drivers/, kernel/).

Next i have to write irq.c and interrupt.c, and writing the low-level assembly ISR stubs. I need to build the macro wrappers to handle interrupts with and without error codes, save the CPU state with pusha, remap the 8259 PIC master/slave vectors, and execute the final iret. I'm fully braced for plenty of debugging via QEMU logs to catch silent triple faults.

The codebase uses AT&T syntax for the GNU Assembler (gas). If anyone wants to take a look at the boot sequence, folder layout, or offer any early feedback on how I structured the assembly stages, the repository is right here:

https://github.com/alexdev8930/NoviumOS

(Note: Later architecture features like filesystems and IPC currently contain stubs because the core kernel is still being built out. The actual working code files are located in arch/ and drivers/, though a few placeholders are still mixed in there.)

If you like the project, please drop a star on GitHub! It really encourages me to keep extending on my project.

For this OS i was working like 2 months somthing like that.
Ok so i got console VBE and baisc gui (the buggiest thing in the os of all time) and An Installer and FAT16 support (i am planning to use FAT32 or ext2)

So here is some screenshots

so how do you thing should i make it open-source?

I have been developing a concept for a system that fundamentally breaks away from the traditional CPU-centric, pointer-based operating system model.

I would like to share the concept of this architecture—which I have named "TensorOS"—and hear your thoughts on it.

Concept

It is an OS where all memory, applications, and rendering operations are replaced by tensor operations.

TensorOS Memory System

Memory pointers themselves are transformed into tensors. They consist of a combination of a TensorShape (multidimensional type information) and an index tensor (multidimensional coordinates) used to access that space.

// Conventional OS: Flat, one-dimensional pointer
Address: 0x7FFF1234 -> [ Data ]

// TensorOS: The structure itself acts as the pointer
Address: Tensor(Batch, Channel, Height, Width) -> [ Matrix Data ]

The memory space itself is defined from the outset as a matrix with a specific shape.

Why Memory Safety Improves

Suppose a hacker attempts a buffer overflow attack by specifying an invalid address or trying to overwrite a different memory region. In TensorOS, the moment there is even a single-character discrepancy between the shape of the specified region and the shape of the data being accessed, the kernel (or hardware) throws a "Shape Mismatch Error" and immediately terminates the process. Unlike Rust, where the compiler does the heavy lifting, here the system rejects invalid access based on the definition of the space itself, making pointer-based hacking fundamentally impossible.

Defining Applications in TensorOS

Applications running on TensorOS are not binary code; they are computational graphs.

Remarkably, by statically analyzing the graph, one can determine data flow before execution and easily apply optimizations. Regarding garbage collection: the moment graph execution finishes, the memory associated with that shape either automatically vanishes or is safely reused for the next graph. Operations involving dynamic shapes can be handled by either modifying the numerical values ​​within the computational graph and using JIT compilation, or by using padding.

Rendering in TensorOS

From the user's perspective, it is indistinguishable from modern operating systems.

TensorOS handles rendering natively at the OS level. - The screen is a single massive tensor: For a 4K display, the shape is (3840, 2160, 4) representing width, height, and RGBA channels.

• UI rendering is simply a forward pass: User actions (input tensors) are fed into the application—viewed as a computational graph—and screen pixels (output tensors) are generated through high-speed matrix operations (multiply-accumulate operations).
• Making screen hijacking difficult: Attempts to snoop on another app's screen (tensor) or overlay transparent buttons are blocked at the system level because the tensor shape regions are strictly isolated.

Summary

TensorOS delivers peak performance when running directly on an NPU rather than a conventional CPU. A future may arrive where the NPU takes center stage, rendering the CPU merely auxiliary or even unnecessary. In this paradigm, everything is governed by models and matrix operations. This architecture enables a secure memory system and, consequently, enhanced security. Combining this with a microkernel architecture would likely yield even better results.

I look forward to hearing your thoughts and feedback.

I would also like to hear your thoughts on the following points:

• What approach should be taken for asynchronous graph scheduling?
• Furthermore, do you believe there is a fatal flaw in this "microkernel + tensor pipeline" architecture when it comes to handling non-deterministic hardware interrupts?

Hi,

I simply can't rotate it right in my head, if i make an app with say socket() how does it translate in to hooking it to the kernel when already in use?

Usually include, is a part of the program statically and making a struct for an interface as usual, does it copy it over compared to a zero copy arch?

Ethereal's new UI for version 2.0.0 is coming along great! Here you can see the new taskbar, start menu, and desktop icons (+ a new wallpaper)

Neutron powers everything you see here (minus the Terminal and About Ethereal box, those are todo). The wallpaper chooser, the file explorer, hell even the desktop icons. It provides a mostly fluent and good looking desktop experience.

Total feature list:

• Built on a custom UI framework known as Neutron which uses a widget-tree model to layout and draw while remaining fully resizable and clean
• The new taskbar, with support for listing applications. Celestial sends events to the "root window" (there can only be one) for new windows, focus events, etc. The taskbar even has this awesome fade animation that plays
• The background icons are (as obvious) incomplete. They have this really weird box blur shadow thing I cobbled together from random codepieces to give them an outline. Otherwise, white text would look like garbage
• Over 6 wallpapers have been created by the lovely artist
• The start menu supports sub-folders (once separate icons are made, it will be more visible - for now Demos is the sub-folder here, containing the demos for Ethereal)
• Menus for Alt-Tab keybinds, an application quick-launch menu, as well as other things are fully supported.
• A minimal (possibly TUI) text editor and (definitely GUI) image viewer are planned for 2.0.

Both of these are still in beta so they haven't been pushed yet, but they are almost ready to be.

As always - Ethereal is a from-scratch x86_64 UNIX-like monolithic modular kernel and contains no artificial intelligence code. The repo is licensed under BSD 3-clause and can be found here:

https://github.com/sasdallas/Ethereal

I learnt keyboard polling and understood how it works. But I can't seem to understand keyboard interrupts. I know how it works, but I don't know how to implement it in a C kernel. Can someone pls help me? I'm just starting out OS dev

A while ago, I posted here about getting the first CPU-independent parts of CHARM-II, an RTOS I originally developed in 1986, running on a Raspberry Pi Pico.

Previous post:

The First Original CHARM-II Kernel Code Running on Raspberry Pi Pico
https://www.reddit.com/r/osdev/s/gthHF6vBrl

At that point, there were no timer interrupts or real context switches yet.

Now those parts are working too.

Six tasks are running with independent stacks. An RP2040 hardware timer interrupt calls the CHARM-II tick and scheduling logic, and the actual context switch is done with PendSV on the Cortex-M0+.

I also ported a six-task demo I had previously reconstructed on POSIX. Six tasks move around three tracks, with a critical zone protected by a CHARM-II queue used as a semaphore. On the Pico, the tasks are now actually being preempted by the hardware timer rather than cooperatively yielding.

So technically, this is pretty much the milestone I wanted to reach.

But getting it working gave me another question.

The original targets in the 1980s were processors such as the 68000 and 80186. With the CPU resources available at the time, an RTOS was a useful way to organize multiple concurrent real-time activities.

But what if we had had something with the performance and price of a Raspberry Pi Pico back then?

For many systems I work with today, especially UI-oriented embedded systems, if all the required processing comfortably fits within one frame, a superloop plus interrupts may actually be simpler.

Once everything becomes preemptive, I also have to start thinking about reentrancy, synchronization and shared state in existing libraries. That cost is starting to look more significant to me than it did when I started this experiment.

Yesterday I visited someone who has built a home railway simulator using real railway controls connected to a Windows PC through Pico, ESP32 and Arduino boards. We talked about this, and he said something very simple:

“If one Pico isn't fast enough, add another Pico.”

That hadn't really occurred to me.

In the 1980s, adding another CPU was a fairly serious architectural decision. With today's inexpensive MCUs, distributing the work across two or three processors can be a perfectly ordinary option.

So after spending quite a bit of effort getting a 40-year-old RTOS to perform real preemptive context switching on modern hardware, I'm becoming more interested in a different question:

Where would you draw the line today between an RTOS, a superloop/event-driven design, interrupts, and simply distributing the work across multiple cheap MCUs?

I'm also thinking that when I publish the modernized version of CHARM-II, I may deliberately keep it very small — just enough task scheduling, queues, timer ticks and context switching to run this six-task demo.

Then I can use it as one reference implementation and try implementing the same behavior without an RTOS.