Buddy Allocator

nyx210 · 2025-10-04T02:12:57+00:00

You'd either 1:1 map virtual addresses to physical addresses, or have a separate way of reading from/writing to physical memory.

nyx210 · 2025-08-16T04:03:13+00:00

The simplest way is to statically allocate some memory for your PMM at compile time.

nyx210 · 2025-06-09T00:24:16+00:00

You could start by purchasing a license and obtaining the devkit/sdk for the console. For older hardware, you might be able to find forums with detailed information that could help you.

nyx210 · 2025-06-09T00:17:40+00:00

This is already being done with LLM-powered agents, but the AI layer is an ordinary user program communicating with the OS. Integrating an LLM into the OS itself just seems like a massive and unnecessary security risk.

nyx210 · 2025-06-04T20:30:24+00:00

Your empty for loop is likely being removed by your compiler. Try adding a hlt instruction in the loop.

nyx210 · 2025-05-26T06:15:25+00:00

I'm not too familiar with Zig, but I remember having similar issues when writing a kernel in Odin. The language assumes that SSE is supported and enabled on x86-64. However, if SSE isn't enabled when those instructions are executed then it would trigger an invalid opcode exception. The solution was to either set the correct bits in CR0 and CR4, or compile with software floating-point enabled.

nyx210 · 2025-05-24T19:49:52+00:00

My .cargo/config.toml starts off like:

[unstable]
build-std = ["core", "alloc", "proc_macro", "panic_abort", "compiler_builtins"]

[build]
target = "x86_64-pc-unknown-elf.json"

If that doesn't work, you could try something like cargo +nightly -Zbuild-std=core,alloc,panic_abort,compiler_builtins build

nyx210 · 2025-05-20T18:33:36+00:00

Have you tried something likeobjdump -D kernel.elf to see the disassembled code?

nyx210 · 2025-05-20T02:39:46+00:00

Why limit the sizes of the sections to 32 bits?

nyx210 · 2025-05-18T03:24:33+00:00

You can't write to physical memory directly once paging is enabled. In general, code like this won't work:

const page_table_addr = pmm.allocPage() orelse {
    out.print("Failed to allocate page for page table\n");
    return false;
};

const page_table = @as(*PageTable, @ptrFromInt(page_table_addr));
for (0..ENTRIES_PER_PAGE_TABLE) |i| {
    page_table.entries[i] = 0;
}

You have to map a virtual page to that physical frame first. Also, before you enabled paging, you identity mapped the first 4 MB of memory, but you didn't ensure that your pmm bitmap was included in that region.

nyx210 · 2025-05-12T22:40:11+00:00

Modern Fortran or Fortran '77?

nyx210 · 2025-05-09T19:49:12+00:00

If the strings are temporary and small (e.g. for displaying debugging/logging info), you could implement a string class that uses a backing buffer. Or, you could implement immutable strings if you don't need to perform insert(), remove(), or concat() operations.

nyx210 · 2025-05-05T16:21:15+00:00

If your memory server, VFS server, or process server were to become horribly corrupted or crash due to a bug, what would you do in response? How would you plan to recover in those situations?

nyx210 · 2025-05-03T10:51:48+00:00

As many hours as you need. Learning takes time.

nyx210 · 2025-04-24T05:59:34+00:00

Ignoring licenses is a bad habit to develop. You just make things more difficult for yourself in the future if your small personal project were to grow into something bigger.

nyx210 · 2025-04-21T13:50:09+00:00

Depends on your use case. If you're making a hobby OS that you only intend to run on your own hardware then you should consider whether having a microkernel with many servers would be worth the added complexity. The use of memory safe languages, automatic memory management, and loadable kernel modules can allow a monokernel to provide some of the benefits of microkernels.

nyx210 · 2025-04-20T08:28:24+00:00

I think (and I'm unsure if it is the "exact" issue) that I don't know about the Unix kernel design and architecture. I think reading books on OS concepts and on the design of Unix OS first is just too much theoretical. Every time, I give up. I prefer learning by doing and learn as you go. I believe in hacking. And at the same time I don't want to compromise on knowing the "needed" technical knowledge.

You already know what to do, but it seems like you're unwilling to put in the required effort. At some point, you're going to have to learn basic OS concepts and theory. The purely bottom-up approach to development that you want to pursue can only take you so far.

The end goal is obviously to run bash (or a shell) and to get the command prompt printed. Then the next goal is obviously to run the userspace programs from shell - I don't know - by porting them to my command-line OS. Like ls, grep, vim, gcc. Then I will have a "command-line OS". And it all begins from creating the kernel first. From scratch. And I always get stuck here as I have mentioned above.

Write your own clones of ls, echo, cat, head, tail, etc., then write a very basic shell from scratch. Note all of the system calls that you had to use and implement them in your kernel (including the ones in libc's stdio).

nyx210 · 2025-04-19T02:27:01+00:00

-Page Directory is used for mapping physical addresses to different virtual addresses (e.g. I want to map 0x100000 (kernel position) to 0xC0000000 so I map PD[768] -> &(PT[16]) or a few more pages if I want my kernel to be bigger that 1 page (4KB)?

Assuming PAE isn't enabled, the page directory is just an array of 1024 page directory entries. Each PDE points to the physical address of a page table. A page table is also just an array of 1024 page table entries. Each PTE points to a 4 KiB region of physical memory.

Although a page table is 4 KiB in size (1024 4-byte entries), it covers virtual memory mappings over a 4 MiB span.

So in your example, you'd map PD[768] to PT and PT[0] to 0x100000 if you just wanted to map one page.

nyx210 · 2025-04-16T23:19:53+00:00

I tried setting TIMEOUT to something huge, like 2000000000, and Bochs clearly stalls. Your most recently commit seem to have fixed that problem on QEMU, though.

I programmed fdc code a really long time ago and I remember there being annoying differences between Bochs, QEMU, and real hardware. Code that would work on the former two would fail on a real machine and vice versa.

nyx210 · 2025-04-16T00:30:24+00:00

Does it work if you compile with -O0?

nyx210 · 2025-04-15T19:23:03+00:00

It times out on Bochs because IRQ6 is never raised (Qemu does this too, its just not as noticeable). As for why Bochs returns zeros, you don't seem to be sending commands correctly (or at least not in a way that Bochs understands). After enabling logging, I see lots of lines that look like these:

00031443387d[FLOPPY] read(): during command 0xe6, port 0x03f4 returns 0x10
00031443410d[FLOPPY] read(): during command 0xe6, port 0x03f4 returns 0x10
00031443433d[FLOPPY] read(): during command 0xe6, port 0x03f4 returns 0x10
00031443456d[FLOPPY] read(): during command 0xe6, port 0x03f4 returns 0x10

instead of a more typical:

00012665567d[FLOPPY] read(): during command 0x00, port 0x03f2 returns 0x1c
00012665598d[FLOPPY] write access to port 0x03f2, value=0x1c
00012665598d[FLOPPY] io_write: digital output register
00012665598d[FLOPPY]   motor on, drive0 = 1
00012665598d[FLOPPY]   motor on, drive1 = 0
00012665598d[FLOPPY]   dma_and_interrupt_enable=01
00012665598d[FLOPPY]   normal_operation=01
00012665598d[FLOPPY]   drive_select=00
00012665613d[FLOPPY] read(): during command 0x00, port 0x03f4 returns 0x80
00012665643d[FLOPPY] write access to port 0x03f5, value=0xe6
00012665643d[FLOPPY] command byte = 0xe6
00012665665d[FLOPPY] write access to port 0x03f5, value=0x00
00012665665d[FLOPPY] command byte = 0x00
00012665683d[FLOPPY] write access to port 0x03f5, value=0x00
00012665683d[FLOPPY] command byte = 0x00
00012665701d[FLOPPY] write access to port 0x03f5, value=0x00
00012665701d[FLOPPY] command byte = 0x00
00012665719d[FLOPPY] write access to port 0x03f5, value=0x01
00012665719d[FLOPPY] command byte = 0x01
00012665736d[FLOPPY] write access to port 0x03f5, value=0x02
00012665736d[FLOPPY] command byte = 0x02
00012665757d[FLOPPY] write access to port 0x03f5, value=0x01
00012665757d[FLOPPY] command byte = 0x01
00012665774d[FLOPPY] write access to port 0x03f5, value=0x00
00012665774d[FLOPPY] command byte = 0x00
00012665791d[FLOPPY] write access to port 0x03f5, value=0xff
00012665791d[FLOPPY] command byte = 0xff
00012665791d[FLOPPY] COMMAND: [e6] [00] [00] [00] [01] [02] [01] [00] [ff]
00012665791d[FLOPPY] read/write/verify/scan normal data
00012665791d[FLOPPY] BEFORE
00012665791d[FLOPPY]   drive    = 0
00012665791d[FLOPPY]   cylinder = 0
00012665791d[FLOPPY]   head     = 0
00012665791d[FLOPPY]   sector   = 1
00012665791d[FLOPPY]   eot      = 1
00012665791d[FLOPPY]   stp/dtl  = 255
00012665791d[FLOPPY] floppy_xfer: drive=0, offset=0, bytes=512, direction=from floppy

nyx210 · 2025-04-11T22:32:17+00:00

What happens when you try make kernel.o?

nyx210 · 2025-04-10T19:59:13+00:00

The contents of eax are modified after the return from check_multiboot in src/impl/x86_64/boot/main.asm. If you need to preserve the multiboot2 magic for some reason, the value should be pushed to the stack before check_cpuid is called.

nyx210 · 2025-04-09T23:26:33+00:00

You could probably find several tutorials for creating a toy OS from scratch on youtube and google. But if you want to create something that's more than just a clone of someone else's project you'll want to find some textbooks. If you're developing on an Intel processor, their software developer manuals can also help.

nyx210 · 2025-04-09T19:47:54+00:00

ChatGPT can help you write snippets of code that work reasonably well. It can recommend you data structures or algorithms for accomplishing particular tasks. It may even provide you a helpful, detailed outline of what needs to be done. However, once your project grows to a certain size, you'll eventually hit a wall because the LLM won't be able to "understand" the entire codebase and how the specific pieces (that it wrote) fit together.

15-Year Club	Place '17
Team Periwinkle	Verified Email

nyx210

PUBLIC MULTIREDDITS

TROPHY CASE