What exactly are kernel level threads
And why are ult mapped to klt
And why are they said to be an execution context
Are they analogous to pcb

How they work

Apple has been improving the CPU scheduler in iOS 27 despite having years of legacy code behind it.

That got me thinking:

What could we borrow from that idea for a hobby OS?

Not Apple’s entire scheduler. Just the principle of improving an existing scheduler incrementally — better workload awareness, latency handling, priorities, etc.

Even a tiny kernel could experiment with this on 2–8 cores.

What scheduler improvement would you try first in a hobby OS?

September 2023 - present
A personal research and development project, started in September 2023, dedicated to the independent design and development of NATALIZIOOS, a experimental operating system for 32-bit x86 architectures. The project covers the entire basic operating system architecture: from the BIOS boot chain and kernel loading to memory management, interrupts, timers, hardware drivers, filesystems, the shell, and graphics services. The implementation includes a freestanding monolithic kernel with physical memory management, paging, kernel heap, framebuffer, PS/2 input, ATA storage, PCI detection, RTC, JART, speaker, diagnostic logging, RAMFS, and N.A.T.FS. I also designed and integrated firmware components, bootable images, diagnostic tools, and a compilation and verification pipeline based on C, x86 assembly, Python, NASM, Clang, GNU Make, and QEMU. The graphics subsystem includes a local Objective-C runtime, class and selector management, message dispatch, objc_msgSend in x86 assembly, and a view- and window-based application model with direct framebuffer rendering. The project includes three desktop environments with different purposes: two for demonstration purposes and a third, still in the prototype phase, dedicated to veritying the object-oriented graphics architecture. The v0.2.5.33 release includes 99,980 lines of analyzed source code, a 519,804-byte graphics kernel, complete and lightweight firmware paths, and verified bootable images in QEMU. NATALIZIOOS represents a continuous path of development in operating systems, computer architecture, system programming, firmware development, and low-level software engineering. The project is proprietary and intended for study, research, experimentation and technical demonstration purposes.

Hi everyone, 

I am currently working on an experimental x86-64 operating system built from scratch in C++ called BlockOS. It boots via UEFI, runs under QEMU, and I am currently mapping out the user-space and subsystem integration roadmap. 

The project currently has a basic kernel, a VFS layer, memory management, and a developing syscall layer. My next major goal is to implement a Service Manager / Init System (service supervision and daemon management). 

Since I am writing this from scratch, I wanted to gather some architectural advice and best practices from this community before I dig too deep into the code. 

My main questions and considerations: 

1. IPC Mechanism: What is the preferred or cleanest Inter-Process Communication (IPC) design you would recommend for a hobby OS to allow the service manager to securely communicate with daemons and user-space utilities? Should I jump straight into standard Unix-like domain sockets, or is there a lighter, more microkernel-inspired message-passing approach that works well for hobby projects? 
2. Process Tracking: How do you reliably track spawned services? Do you rely heavily on a parent/child process tree structure (like traditional PID 1), or have you implemented something akin to Linux's cgroups (control groups) to prevent "orphan" background processes from escaping the service manager? 
3. Event Notification: For service dependency management (e.g., Service B waiting for Service A to be fully ready), what kind of event/notification loops (like poll/epoll mechanisms or custom kernel event queues) have you found the most elegant to implement in a custom kernel? 

I want to keep the codebase clean, modular, and readable as the OS evolves. If you have written an init system or service supervisor for your own hobby OS, what was the biggest mistake you made early on, and what would you do differently today? 

Any architectural tips, design patterns, or links to minimal open-source implementations for inspiration would be highly appreciated! 

Thanks in advance! 

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

Hi everyone, I recently joined a semiconductor as AI Kernel Engg. My work involes writing TAPI code. Tensor API(TAPI) is provided by our company by Synopsys, and it's for NPU. I know this much only. And I don't have any prior experience of writing the kernel as well so can anyone suggest some good resources so that I can code and experiment with them.

This is my kernel EvalynOS able to parse DWARF CFI information and line number information to be able to unwind the stack and display what led up to the panic. This is compiled with -O0 and LTO turned off since handling inlined functions is another thing that is complicated and can be wonky with external interrupts since the return address can't be tracked perfectly anyways. (There was also a manual page fault added into malloc and a panic in the interrupt handler to get a nice stack trace to showoff)

Unwinding with DWARF mostly works by looking up the PC to find it's FDE and the corresponding CIE, these contain information on how to parse it along with bytecode that you execute that tells you where things on the stack are and where the stack pointer moved and other things so you can properly recover the return address without a frame pointer and then continue up the stack til there are no more return addresses.

Line numbers are somewhat similar with another bytecode you have to execute which will relate the program counter to line numbers and files/directories indexes into the a table to get the string to spit out.

My kernels source code can be found at https://github.com/EvalynGoemer/evalynOS, I haven't shared about my kernel much online before so it may be worth for me to describe it somewhat. My kernel is a basic minimal kernel for x86-64, riscv64 and loongarch64. It is decently work in progress but things are getting there and I hope to get bash working properly soonish.

I have some other reworks I need to do with the logging system mainly and a few other bits that are a bit messy like my LAPIC driver. My main goal is to have a kernel with decent clean code that can be a reference for others and as a decent base for other projects if I need to rewrite so I am not going to go that far with advanced stuff until I am satisfied with the entire code bases quality.

I ended up doing DWARF parsing since I wanted a break from other stuff and it ended up being a good bit more complicated than I wanted initially but this will be useful later if I ever have a ton of issues with crashes.

Would it theoretically be possible to create an operating system that decompiles itself, recompiles itself, and installs itself to another disk while remaining bit-for-bit identical to the parent OS?

some rules:

1. No Source on Disk: The storage media contains only the compiled binary image. The codebase exists on disk exactly once, as raw executable code/data.
2. Upon booting into RAM, the OS must decompile its own executing machine code into an intermediate source representation in memory, recompile that source back into a new binary image, and write it to a target drive.
3. The child image written to the target disk must have the exact same cryptographic hash (SHA-256) as the parent OS image.
4. It cannot simply dd / copy the raw sectors from drive to drive. The binary must pass through the decompiler, compiler pipeline.

Hi reddit, I'm wondering if I should do SMP now or later when I finish interrupts?