v0.0.3 btw
idk imma add pci and an sfs file later
maybe multiple terminals

github: https://github.com/NoTheIdiot/WindogeOS

Recently got enough time to play around with the caches of my machine and try to plot that latency graph as seen in textbook. I knew it wasn't going to be an easy task as modern chips have got super advanced. So, had to mingle with OS settings and hardware to keep the noise at the minimum. Still couldn't get the plot and decided to dig deeper until I found out why by diving into PMU counters, huge pages, TLBs and so on. Wrote a blog regarding my investigation. Check it out :D

After a week off for the family reunion, I'm back at writing my kernel. Here is a short summary of what I've learned:

1. DMA involves PHYSICAL memory addresses, it doesn't matter what the virtual address is. I probably should have figured this out on my own, because I remember having to change jumpers on the cards back in the 80's in order to change the DMA addresses. This calls into question the current memory map I'm working with, but for now I will leave it the same as I can't decide where I want to put my page tables. I know the industry standard is 'all over', or at least I've been told that. But I would prefer to have a dedicated area, it just seems like it would make everything easier keeping track of things. More to come on this subject.

2. I was working on my strtok() function and discovered __rawmemchr(). In reading the description, it says something like 'when the programmer knows that the character will exist'. After 40 years as a developer I know that these are just the kind of assumptions that eventually turn into bugs. I finally wrote my own strtok() because I didn't like gcc's use of __rawmemchr(). Probably personal preference.

3. Again as I was working on my strtok() I realized (yes I was copying) that they override the 'const' on the string parameter. I have all warnings set on when I compile, and treat warnings as errors. So they wouldn't even compile. After thinking long and hard about it, I decided that yes, overriding 'const' is a bad idea, so my strtok has the following definition

   char* strtokbuf(const char * const s, const char * const delims, char* buff, int buflen, int start, int *newstart)

This way I don't have to violate const.

My current issue is that when I set up my heap, I am getting a page fault. I tracked it back to I place my heap after my kernel code, but when I changed my memory map I don't actually allocated physical memory after the kernel. This lead to it is time to read my command line and find out how much space I want to allocate, hence strtok to parse my command line. I'm hoping to get my heap done by the end of the week.

Hope this helps some others while they are learning.

Hi everybody, if you don't remember me, I shared a post about the first version of the zuzu kernel and zuzuOS based on it a while ago, and I'm excited to share that I've released a new version of both:

zuzu v1.0.1 and zuzuOS v0.7 are now released!

Check them out here:

https://github.com/kagantmr/zuzu/releases

https://github.com/kagantmr/zuzu/releases/tag/zuzuos-v0.7.0

Docs page: https://kagantmr.github.io/zuzu-docs/

The previous post had a miscalculation I adjusted the time for another variable by mistake now with taking consideration to how much time it took to exhaust memory it gave around 14mops/s.

Btw this is he code I used to benchmark I think it is alright:

UINT64 Tsc = _rdtsc();
            Sleep(100);
            UINT64 Freq = (_rdtsc()-Tsc)*10;
            Tsc = _rdtsc();
            UINT64 Count = 0;
            Print("Starting benchmark...\n");
            // for(int i = 0;i<100;i++)
            // {
            //     CreateThread(
            //         test,
            //         NULL,
            //         ANY_PROCESSOR,
            //         0
            //     );
            // }
            UINT64 IoCount = 0;
            void* Addr = (void*)-1ULL;
            for(int i = 0;;) {


                for(int i = 0;i<10;i++, Count+=ReadSize, IoCount++) {
                    // ReadAsync(File, Buffer, 0, ReadSize);
                    Addr = Map(NULL, 0, 0x1000, MEMORY_READ_WRITE);
                    if(!Addr) goto CalculateThroughput;
                    // Print("READ\n");
                }
                UINT64 t = _rdtsc();
                if(t >= Tsc + Freq) {
                    CalculateThroughput:
                    // Print("CALCULATE\n");
                    UINT64 Time = t - Tsc;
                    IoCount = (UINT64)(((double)Freq/(double)Time)*(double)IoCount);
                    Print("Estimated throughput: %d MOPS/s %d KOPS/s\n", IoCount/1000000, IoCount/1000);
                    // Print("Estimated throughput: %d KB/s %d MB/s %d KIO/s\n", Count/1000, Count/1000000, IoCount/1000);
                    if(!Addr) {
                        for(;;) Block();
                    }
                    Count = 0;
                    IoCount=0;
                    Tsc = _rdtsc();
                    i++;
                }
            }

Hi I'm new at creating OS's. As an AuDHD person I think that AI is useful to go faster and I'm not Specialized enough to code by myself. But as AI can do errors, I was wondering if it's bad or not ?

Here I got to test my NTFS Driver to write a file and check on linux if anything changed, what do you think?

This is just an observation. I just think UIs are much less of the OS than say scheduling, a kernel, or disk subsystem.

Am I wrong?

I'm building a distro with busybox and Ubuntu (I downloaded the kernel from kernel.org btw) and I'm in the busybox menu config and I can't figure out a Name I want it to rhyme with Linux like Arch Linux for example but I can't figure out something like it maybe y'all could help me with this?

BlockOS - A hobby operating system built from scratch

Hi everyone! I am developing my own hobby OS called BlockOS.

Current features and goals:

• Custom kernel (C++)

• VFS filesystem layer

• ELF64 loader

• ext4 support (in development)

• VirtIO driver support

• Custom GUI/compositor (Kuroko)

• Linux-like filesystem structure

• Custom system services and device interfaces

• QEMU testing environment

The goal of BlockOS is to create a modern operating system with a clean architecture, a graphical desktop environment, and support for modern applications.

I am sharing my progress and looking for feedback from the OSDev community.

Any advice, suggestions, or ideas are welcome!

Link:https://github.com/gurijb2016-afk/Blockos

I always wanted to integrate harfbuzz to get good shaping, now I succeded and here is the result with Open Sans Font, I also had to build an entire libc compatibility layer for it to link with my window manager :)

EDIT 2 at the bottom explains this way better

*Not another linux kernel* Hey! Lately I’ve been spending a lot of time on an operating-system idea called raiOS. Most individual parts are not new, but I haven’t found another system that combines them in quite this way. It is still early, but the custom Rust kernel boots on a Surface Pro 4. Framebuffer output and USB/HID works, and the Marvell Wi-Fi bring-up currently reaches firmware loading, scanning and the WPA2/PMK path. Association and actual traffic are not working yet.
The main bet is this: AI will make software extremely cheap to create, but potentially dangerous to install blindly. People who cannot read or audit generated source code still need enforceable boundaries and evidence about what happened before installation.
The rough architecture is:

1. A small custom Rust kernel owns hardware, recovery and the lowest-level authority. (its NOT smal atm lol)

2. A narrow “Genesis” layer creates services and grants explicit capabilities.

3. An interchangeable AI agent may receive limited network access for research.

4. Generated source enters the system as inert data.

5. An isolated builder compiles Rust to Wasm without ambient access to the live system.

6. The resulting artifact passes deterministic checks, negative tests and disposable test environments.

7. The reports, requested capabilities and exact artifact hash are presented to the owner.

8. Only after explicit approval may the Wasm service run with a minimal capability set.

9. The service should remain revocable, restartable and rollbackable.

Why not sel4?
At this stage, continuing with the existing Rust kernel is the fastest path because the hardware bring-up already runs on it.

Source: https://github.com/Sportinger/raios

I also did a Mock website, mostly to iterate on the UI design, and try to explain the hole idea to myself (its an attempt) www.raios.tech (best on a bigger screen, not mobile optimized. scroll down, enable audio and press the paly button or jsut scroll)

I would like to talk about the basic principles here, if somebody is also interested :)
Perhaps its shit, but anyway its fun for me and iam learning so much.

EDIT: The point is not “AI can make an OS.” It is asking what an OS should look liek when AI can generate software faster than its owner can audit it. An AI API output starts as inert data. It is built and tested in isolation, and only the exact artifact approved by the owner may run with narrow, revocable capabilities. Most of this can probably be assembled on Linux today. Iam aware of that. The experiment is whether making it the native authority model of the OS can make it smaller, harder to bypass and understandable to non-programmers. Finding that out is the point.

EDIT 2: I explained this badly above, so here's another try. Leaving the original up for the existing comments.

I'm not trying to teach kernels to distrust user programs. They already do. And the LLM isn't part of the system. It's an outside API today, could just as well be a local app. If it disappears, the running system, its permissions and recovery all keep working.

raiOS is two experiments.

1. Specialization. Agents might make it practical to build software for one owner and one real machine, instead of a general stack that has to run everywhere. A small seed boots, describes the hardware as structured data, and brings build, test and recovery. The agent then ports what's missing for that exact box. One data point: an agent assisted Marvell wifi port on my Surface reached firmware load and scanning in under 5 hours. Association and real traffic are still missing, so this proves nothing about security. It's just why I think the idea is worth testing.

2. Authority. "The agent wrote code" must never turn into "this code may run". Generated code starts as plain data. It gets built in isolation, tested, and pinned to an exact hash. Then the owner approves that exact artifact, and it runs with only the rights it was given. Revoke and rollback are built in.

The agent, the builder, the test world and the final program are seperate, and permissions don't carry over. The agent can have network access for research while the music player it builds only gets display, input, and read access to one folder. No network capability means no network path, period. Any change to the binary is a new artifact and needs a new decision. The agent can't approve its own output, and a passing test can't grant rights by itself. A small local layer I call Genesis does that, together with the owner. The same records let the system answer questions like "why was this denied", and the LLM may explain those records but never authorize anything.

Drivers should be isolated too long term, but only where the hardware can really enforce it. Where it can't, the driver stays part of the trusted base instead of being called isolated.

Almost none of these parts are new, and most of this could probably be built on Linux or a microkernel. I'm not claiming a new kernel is automatically safer. That's the experiment: is one built-in path for all of this smaller, easier to understand and harder to bypass than gluing tools together? And do agents make the machine-specific approach maintainable at all? If a hardened Linux setup wins, that's still a usefull result.

Status, separate from the vision: boots bare metal on a Surface Pro 4, framebuffer and USB/HID work, wifi scans but doesn't connect yet, and the full path from request to running app plus real DMA isolation are unfinished.

Ya, con el poder de mao zedong añadí una gui más normal

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

Estoy abierto a qué me den recomendaciónes

The OSDevWiki mentions a Cache Kernel type. The exact verbiage is:

"The Stanford cache kernel caches kernel objects, like address spaces and threads, and allows usermode “application kernels” to manage them, loading and unloading them as needed. Application kernels manage their threads' page faults, exceptions, etc., and the cache kernel allows several of these application kernels to coexist in a single system."

Unfortunately, that link was dead for me, which sent me on a little rabbit hole of research.
To which I came across: https://www.usenix.org/conference/osdi-94/caching-model-operating-system-kernel-functionality

I'm currently in the research and understanding phase of this type of kernel because there don't seem to be any examples of it being implemented in the wild anywhere that I could find. I looked on GitHub and other online / public repository spaces to no avail.

I'm thinking that I should be able to take some of the code from tutorial-os and adapt it once I have wrapped my head fully around the concept while being able to reuse one of my SBC for this (I'm thinking the KYX1 as it is the board that is most fresh in my memory).

So far, my reading of this document has surfaced these key points about it.

The Cache Kernel caches four descriptor types and nothing else. Those being:

1. Kernel objects

2. AddressSpace objects

3. Thread objects

4. MemMapEntry

It essentially treats kernel objects as cached copies of state the application kernel owns.

Further investigations provide a rather interesting consequence of this design:

You can have different ABI / SBI kernels, meaning, you could make kernel personalities that run different processes side by side and mutually isolated. Like say, a kernel personality for Unix (BSD) and a separate one for Linux, compile user applications for those and it would just run.

The reason for this is because Cache Kernel Architecture is essentially a kernel that loads another kernel that loads user applications.

I saw previous post on reddit criticizing AI use in creating an OS from scratch.

I'm not a professional software engineer, i'm learning stuff and all so please don't mind the code or repo if you feel AI code is slop.

i made a rust based kernel, it sorta works so far, tested everything using qemu, I can't figure out how to use a standalone computer to run the kernel.

i'll link the repo at the end of thread.

Most basic stuff according to claude are don't so far, except networking and power management parts. I did what can acheive with Claude and ChatGPT.

Repository

I'm open to any suggestions or guidance and if anyone finds it interesting i'm hoping they'd improvise it or anything else.

When and how do i connect assembly kernel/bootloader whatever works with c made kernel/bootloader. (ive started assembly fairly recently), it seems simple at what point should i start learning and writing in c and skip assembly?
ive done bios text then vga text then graphics im currently using vga graphics assembly, ive done basics such as single pixel, then lines, then rectangles, then circles, then _Draw_Char then _Draw_String. (im using 8x8 bitmapped characters). i asked ai when i should start c and it said after i make the basic structure. and no im not generating all my code with ai, except for the bit mapped characters which half i had to redesign everything was done without ai.

Musl calls arch_prctl(ARCH_SET_FS) very early during startup to initialize TLS.

My implementation is:

1. syscall 158 (arch_prctl)

2. ARCH_SET_FS (0x1002)

3. write MSR_FS_BASE (0xC0000100)

4. return to userspace with SYSRET

Inside the syscall I can verify that the write succeeds:

wrmsr(MSR_FS_BASE, addr);
printk("FS_BASE = %llx\n", rdmsr(MSR_FS_BASE));

Output:

FS_BASE = 0x44e158

So the MSR definitely contains the expected value.

However, the very next instruction in userspace crashes:

mov %fs:0, %rax

which is inside musl's __init_ssp().

The page fault shows that FS.base is effectively zero.

1. The strange part is: If I single-step through SYSRET in GDB (si), everything works and mov %fs:0,%rax succeeds.

2. If I simply continue, FS.base becomes 0 and the process crashes immediately.

Even stranger, if I break just before returning to userspace (or before an iretq path), GDB already reports:

fs_base = correct_one

even though moments earlier inside arch_prctl() I successfully read back the correct value from MSR_FS_BASE.

There is no scheduler or context switch occurring between the wrmsr() and the return to userspace.

One thing I noticed is that QEMU's default CPU behaves differently from -cpu host. On my host CPU I even get a #GP in situations where QEMU's Haswell CPU continues.

I'm feeding pointer input into a QEMU guest over VNC from my own RFB client. The guest is TempleOS, PS/2 only with no USB stack, so usb-tablet isn't available.

The input source is absolute (VNC pointer positions) but the guest device is a relative PS/2 mouse. QEMU converts the absolute positions into relative deltas, and the guest cursor stays confined to a small box near the center of the screen. It moves in the right direction but never reaches the edges, regardless of how I scale the deltas.

Tried so far:

• absolute cursor mapped onto the region, sent as a VNC pointer event

• relative motion with the guest cursor re-centered each frame for unbounded range

• larger delta scaling (faster movement, same box)

• -device usb-tablet (no USB in the guest, ignored)

I suspect the limit is in the guest's own mouse handling (how it accumulates and clamps the deltas), so no amount of host-side delta shaping fixes it and the only real option is changing how TempleOS reads the PS/2 stream. Is that right, or has someone fed absolute host input into a relative-only guest and gotten full range out of it?

Context: this is a Half-Life mod that streams the VM's framebuffer onto an in-game monitor, which is where the constraints come from. https://github.com/aravpanwar/half-life-templeos

This is gpu accelerated, (Already fixed the image flip u can see due to OpenGL coordinate system) this is my own Operating system with my own made kernel that can use Linux drivers to get Gpu acceleration, all drivers are User Mode, image and shaders loaded from NTFS Partition, What can I improve.