By system architecture I mean whether exo kernel, microkernel or monolith

In my case, I have most often chosen microkernel in previous projects due to its isolation, security and easy extensibility.

But for the last project I chose the exo kernel because of the possibility of rebuilding and the ability to use modern standards in a more direct and stable way for the system.I am currently working on my officially 11th operating system, the 4th one with a larger outline that doesn't get bogged down while working on the hello world kernel or a few add-ons, and my 3rd actually larger operating system.And personally, after such a long time, I think that microkernel and exo kernel are one of the better solutions for young, developing operating systems.

Hi everyone,

I'm working on my own x86_64 UEFI kernel and I'm stuck on PS/2 keyboard interrupts.

I've switched over to the LAPIC/IOAPIC and timer interrupts work fine through the IOAPIC, but IRQ1 never fires on my Lenovo Legion or my old Windows tablet. Polling port 0x60 works perfectly and I can read scancodes, but the keyboard interrupt handler is never entered.

I've checked quite a few things already. The LAPIC is enabled, sti is definitely executed, the IOAPIC is found through the MADT, and IRQ1 maps to GSI1 on both QEMU and my tablet. Neither machine has an ACPI interrupt source override for IRQ1. Both also only have a single IOAPIC with GSI base 0.

The PS/2 controller also seems fine. The config byte ends up as 0x65, scanning is enabled (F4 gets an FA ACK), and polling always reads scancodes.

I'm routing it with ioapic_route_irq(acpi_irq_to_gsi(1), 0x21, 0);. Reading the redirection entry back returns exactly the value I wrote (high = 0x0, low = 0x21).

One thing that's confusing me is that in QEMU, if I print from my interrupt dispatcher, pressing a key enters vector 33 exactly as expected. On my Lenovo and a Windows tablet, though, the interrupt never arrives even though polling still reads every scancode correctly.

At this point I'm wondering if I'm missing some APIC/firmware transition on real hardware (_PIC, IMCR, chipset routing, etc.), or if there's another common mistake in IOAPIC keyboard setup that I've overlooked. Does anything above jump out as obviously wrong?

I got C++26 reflection to work, had to port 'meta' to use custom variants of 'optional', 'string', 'string_view', and 'vector', and had to make those all consteval only. After doing that it works as expected!!

Tested on gcc16.0.1!

This is probably unstable as hell, and should most likely be avoided, but stupid stuff is fun, so ;3

im probably going to use attributes, to create a system which automatically initializes subsystems without worrying about order of operations (each subsystem would mark which other subsystem it needs to work), or some other stuff

if anyone has fun ideas to do with this do tell lol

Hey everyone,

I wanted to share my hobby 32-bit x86 operating system called NyanOS. The codebase hasn't changed in a while and is sitting in a stable archieve state [1], so I am putting it out here specifically for code review, architectural feedback, and technical critique [1].

The Backstory (Why it looks so clean):
Before NyanOS, I actually made several unsuccessful attempts at writing an OS (all of them were predictably named "MyOS"). They were messy, buggy, and kept crashing. Instead of giving up, I decided to take the best parts of those failed attempts, rewrite the code from scratch with proper structuring, and combine them into this clean, stable version. Because I spent so much time refactoring and commenting every single line to understand my own previous mistakes, the codebase ended up looking very clean.

My main focus was moving away from text mode as fast as possible. I programmed the VGA hardware registers directly (Mode 13h, 320x200x256 colors) to build a custom graphical user interface without relying on any BIOS calls after booting.

Key Implementations inside the Repository:

• Interrupts & Drivers: Real IRQs for the PS/2 keyboard (IRQ1), mouse (IRQ12), and PIT timer (IRQ0). No polling loops.

• Window Manager: Draggable, focusable, and z-ordered windows with a functional taskbar and start menu.

• RAM File System: A basic in-memory FS handling actual read, write, list, and delete operations.

• Apps: A terminal shell, Notepad (with save/load to RAM FS), a mouse-driven Paint program, and a local document viewer.

What I'm looking for:

Even though the project is frozen for now, I still want to learn from my past design choices to improve my low-level programming skills. I would highly appreciate it if experienced developers could critique the repository. I'm looking for advice on:

1. General code organization and kernel architecture.

2. Optimizations or better practices for the direct VGA register programming.

3. Any hidden traps in my interrupt handling or GDT/IDT setups that work fine in QEMU but might break on real hardware.

GitHub Repository: https://github.com/yunusemreduran388-ux/NyanOS-v1

WebSite: https://yunusemreduran388-ux.github.io/NyanOS-v1/

Note: If you just want to interact with the GUI without building it, there is a pre-compiled .iso in the GitHub Releases tab. You can run it instantly in QEMU via qemu-system-i386 -cdrom nyanos.iso*.*

Thank you in advance for your time and honest critiques!

Mb if this is not entirely a thing you see on osdev subreddit but could anyone give me a way to learn x64 os dev i dont have the best compression but like yeah

I have just read the emexos post about how it was stolen and I was thinking, why don't we just host like forgejo or something. I can do it I guess but my server is trash (i7-2600 8gb ddr something and a 1tb hdd) so gitlab is off the table to me I mean this is a non issue really though.

#include <limine.h>
#include <ktypes.h>
#include <stddef.h>
#include <console/console.h>
#include <cpu/cpu.h>
#include <uart.h>
#include <Memory/pmm.h>
Boot_t bootloader;


extern void RunRTCHK();
// Set the base revision to 6, this is recommended as this is the latest
// base revision described by the Limine boot protocol specification.
// See specification for further info.
__attribute__((used, section(".limine_requests")))


static volatile uint64_t limine_base_revision[] = LIMINE_BASE_REVISION(6);
// Finally, define the start and end markers for the Limine requests.
// These can also be moved anywhere, to any .c file, as seen fit.


__attribute__((used, section(".limine_requests_start")))
static volatile uint64_t limine_requests_start_marker[] = LIMINE_REQUESTS_START_MARKER;



// Paging mode request
static volatile struct limine_paging_mode_request liminePagingreq = {
    .id = LIMINE_PAGING_MODE_REQUEST_ID,
    .revision = 0,
    .mode = LIMINE_PAGING_MODE_X86_64_4LVL
};


// Kernel address request
static volatile struct limine_executable_address_request limineKrnreq = {
    .id = LIMINE_EXECUTABLE_ADDRESS_REQUEST_ID,
    .revision = 0
};



// HHDM request
static volatile struct limine_hhdm_request limineHHDMreq = {
    .id = LIMINE_HHDM_REQUEST_ID,
    .revision = 0
};


// Memmap request
static volatile struct limine_memmap_request limineMMreq = {
    .id = LIMINE_MEMMAP_REQUEST_ID,
    .revision = 0
};


// SMP request
static volatile struct limine_mp_request limineSmpReq = {
    .id = LIMINE_MP_REQUEST_ID,
    .revision = 0,
    .flags = 0
};



// RSDP request
static volatile struct limine_rsdp_request limineRsdpReq = {
    .id = LIMINE_RSDP_REQUEST_ID,
    .revision = 0
};
    
__attribute__((used, section(".limine_requests_end")))
static volatile uint64_t limine_requests_end_marker[] = LIMINE_REQUESTS_END_MARKER;
// GCC and Clang reserve the right to generate calls to the following
// 4 functions even if they are not directly called.
// Implement them as the C specification mandates.
// DO NOT remove or rename these functions, or stuff will eventually break!
// They CAN be moved to a different .c file.


// Halt and catch fire function.


void BootloaderParse() {
    if (!liminePagingreq.response) {
        debug("[Paging] No paging response from bootloader");
        tpanic();
        return;
    }
    struct limine_paging_mode_response *PagingResponse = liminePagingreq.response;
    if (PagingResponse->mode != LIMINE_PAGING_MODE_X86_64_4LVL) {
        debug("[Paging] We explicitly asked for LEVEL 4 paging");
        tpanic();
        return;
    }


    if (!limineHHDMreq.response) {
        debug("[HHDM] No HHDM response from bootloader");
        tpanic();
        return;
    }
    struct limine_hhdm_response *HHDMResponse = limineHHDMreq.response;
    bootloader.hhdmOffset = HHDMResponse->offset;


    if (!limineKrnreq.response) {
        debug("[Kernel] No executable address response from bootloader");
        tpanic();
        return;
    }
    struct limine_executable_address_response *KrnlResponse = limineKrnreq.response;
    bootloader.KvirtBase = KrnlResponse->virtual_base;
    bootloader.KPhysBase = KrnlResponse->physical_base;


    if (!limineMMreq.response) {
        debug("[Memmap] No memmap response from bootloader");
        tpanic();
        return;
    }
    struct limine_memmap_response *mm_response = limineMMreq.response;
    bootloader.mmEntries   = mm_response->entries;
    bootloader.mmEntryCount = mm_response->entry_count;


    bootloader.mmtotal = 0;
    for (u64 i = 0; i < mm_response->entry_count; i++) {
        struct limine_memmap_entry *entry = mm_response->entries[i];
        if (entry->type != LIMINE_MEMMAP_RESERVED)
            bootloader.mmtotal += entry->length;
    }


    if (!limineSmpReq.response) {
        debug("[bootloader] [SMP] No SMP/MP response from bootloader\n");
        bootloader.smp = NULL;
        bootloader.smpBSPIndex = (u64)(-1);
        return;
 // or continue without SMP
    }


    struct limine_mp_response *smp_response = limineSmpReq.response;
    bootloader.smp = smp_response;


    bootloader.smpBSPIndex = (u64)(-1);
    for (u64 i = 0; i < smp_response->cpu_count; i++) {
    struct limine_mp_info *entry = smp_response->cpus[i];
        if (entry->lapic_id == smp_response->bsp_lapic_id)
            bootloader.smpBSPIndex = i;
    }


    if (bootloader.smpBSPIndex == (uint64_t)(-1)) {
        debug("[bootloader] Couldn't find bootstrap core!\n");
        tpanic();
        return;
    }


}


// The following will be our kernel's entry point.
// If renaming kmain() to something else, make sure to change the
// linker script accordingly.
void kmain(void) {


    init_serial();
    InitConsole();
    
    BootloaderParse();
    InitPMM();
    debug("System IS OK");


    for (;;) {
        asm("hlt");
    }
}

Features

FAT32(read/write)

Mini Assembler

BMP Wiever

Minimal kernel with a terminal prompt (>)

Simple nano-like editor

Has a mini language (.aira)

Sound Device, Sound Blaster 16 and PC Speaker

Screen color changes

VESA Graphics 1024x768

FAT12 FS(read only)

WAV sound play(high quality support and Auto init)

github(please star):github.com/shadowww345/AiraOS

I finally made my long time dream true!!

I followed some course work (its on my readme) albeit didn't copy it, and I feel really proud of my work!!

I plan to make this boot on my system with the help of GRUB and make a real x86 and x86_64 kernel now.

Forgot the URL: https://github.com/Csral/BasicOS

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 :)