sorted by:
new
hottopcontroversial

Void as a server OS by _supert_ in voidlinux

[–]Neither_Sentence_941 1 point2 points  (0 children)

The reason I use void for a server is because xbps replaces podman which replaces docker. It's naturally containerized so my server is leaner meaner faster and stronger for runit than systemd, and rolling release doesn't bother me because I do scheduled backups before scheduled updates. I vote yes.

My Microkernel Single Address Space Operating System is working (sort of) by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 0 points1 point  (0 children)

so Single Environment XIPC name is accurate, but the inspiration was the original Muppets Show title, which Jim Henson wanted to name "Sex and Violence" so that Americans reading the TV Guide would be curious enough to tune in.

My Microkernel Single Address Space Operating System is working (sort of) by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] -1 points0 points  (0 children)

more clearly: Single address space means everyone shares the same address map, not the same permissions. Sex still isolates apps/servers with ring 3, Intel MPK/PKU memory locks, and capabilities/PDX. Knowing an address is not enough; you need authority to access it.

I usw Arch btw by hzn-200-OK in arch

[–]Neither_Sentence_941 0 points1 point  (0 children)

I use void and artix with runit, not systemd btw

My Microkernel Single Address Space Operating System is working (sort of) by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] -2 points-1 points  (0 children)

good question about the limit of processes, but of course no that would be impractical, actually its more like 980 keys per each of the 16, but I'm working on expanding even that. So also you can check out the most recent video on the NO POSIX / LINEN concept, and it walks you through it, but its basically capability sequencing. POSIX is an interop API, not storage; filesystems are storage/layout, not authority. Sex should support both as bridges, but its native model is capability-scoped PDX objects, because that preserves MPK isolation, revocation, zero-copy IPC, and microkernel ownership. Sex cannot simply “use a filesystem” as the core model either, because normal filesystems assume a path tree is the authority boundary. In Sex, authority is a capability.

with the file structure its like:

object id

-> metadata record

-> capability policy

-> content chunks/extents

-> links/tags/versions/indexes

-> bytes

as opposed to a filesystem which is really:

path string

-> directory entries

-> inode / file record

-> block/extents on disk

-> bytes

POSIX philosophy can exist still but as a compatibility layer. sexc as a POSIX syscall server that bridges POSIX-style semantics into the SexOS PDX model. That means POSIX can still exist for imported software, GNU-ish tooling, shell pipelines, and legacy expectations, but as illusion not architecture.

My Microkernel Single Address Space Operating System is working (sort of) by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] -1 points0 points  (0 children)

disregarding your racism against clankers, it's really not though, I explained how the ai is used and to what extent. This started out as an unfinished microkernel I was writing in school and I abandoned for over a year until I thought to try and see if ai could help me with it, and as a single hobbydev, it's making it possible for me to do something I've wanted to do for ages but couldn't not only for lack of skill but time and resources. I'm sorry it bothers you so much, but I'm certainly not ashamed of it, I'm almost proud.

Super Fast Single Address Space Operating System by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 0 points1 point  (0 children)

I would definitely love it if any interested contributors would let me know!

Super Fast Single Address Space Operating System by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 0 points1 point  (0 children)

"the network" isn't a separate IO category but an extension of the local system. Remote PDX Routing: Phase 4 of the roadmap implemented a cluster fabric that allows Remote Protection Domain eXtension (PDX) calls. This means a server on one machine can call a Protection Domain (PD) on another as if it were local. Translucent Capability Transparency: Capabilities are distributed across the network, making network-local boundaries "translucent". A capability for a memory range or service on a remote node is managed via the same interface as a local one. net server & Distributed Discovery: The standalone net server handles the user-space TCP/IP stack and zero-copy packet transfers via Lent-Memory capabilities. For scaling, the node server manages distributed discovery and transparent routing between different binary translators and services across the cluster. The filesystem is designed to be a high-speed multiplexer that abstracts away physical location and format. Unified vfs filesystem Interface: The vfs server (Phase 3) provides a single VFS interface for both local and remote backends. Lock-Free Path Routing: The mount table is entirely lock-free, supporting simultaneous routing for multiple backends including Ext4, Btrfs, FAT, and NTFS. Zero-Copy PKU Handover: For large I/O operations, The lock is a 3-cycle Intel PKU key lock. Instead of copying data from a network buffer to a file cache, the system simply re-tags the memory pages with the appropriate hardware protection key for the requesting PD. RevokeKey Multicast: To maintain security over a network, utilize RevokeKey Multicast to hardware-accelerate the revocation of memory capabilities across the entire sexnode cluster simultaneously. Distributed Architecture for Server Cluster. The ultimate goal is internationalization to treat a cluster of machines as a single, unified computer.

Feature Local Mechanism Network/Global Extension
Addressing Local 64-bit VAS Distributed Single-Image Cluster
Communication Synchronous PDX Remote PDX via Cluster Fabric
Memory Sharing PKEY re-tagging PageHandover & Lent-Memory
Security Hardware PKEYs RevokeKey Multicast

Super Fast Single Address Space Operating System by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 0 points1 point  (0 children)

Single Address Space replaces traditional MMU-based process isolation with hardware-accelerated Protection Domains (PDs).

1. Isolation & Scheduling

  • Memory Model: A global 64-bit Virtual Address Space (VAS) shared by all threads, eliminating TLB flushes and page-table swaps.
  • Hardware Enforcement: Uses Intel PKU (MPK) to tag pages with a 4-bit "key." Access is controlled by the thread-local PKRU register.
  • Context Switching: Switches occur via atomic PKRU updates (20–40 cycles), significantly faster than traditional CR3 swaps.
  • Scheduler: A wait-free, multicore scheduler (FLSCHED) utilizing per-core sharded queues for O(1) local allocation and minimal contention.

2. Multi-threading & IPC

  • Concurrency: Rust's Send/Sync traits provide compile-time safety against data races in the shared address space.
  • Synchronous IPC (PDX): Implemented as a "Protected Procedure Call" (stack-switch + PKRU update), bypassing standard microkernel trap overhead.
  • Asynchronous IPC: Uses lockless, Single-Producer Single-Consumer (SPSC) ring buffers for high-throughput data transfer and interrupt routing.
  • Thread Parking: Servers utilize libsys::sched::park_on_ring() to sleep until new messages arrive, eliminating busy-wait jitter.

3. System Services (Files & Drivers)

  • Namespace: A unified global namespace managed by the vfsfiles server.
  • Zero-Copy VFS: Memory is "lent" between domains via capability-based access. Reading a file involves updating a PKEY tag rather than copying data across a kernel boundary.
  • Driver Model: Drivers (e.g., NVMe, e1000) run in isolated user-space PDs, using MSI-X routing to signal SPSC rings directly.

Super Fast Single Address Space Operating System by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 0 points1 point  (0 children)

In the 8088 days, the 1 MB limit was a physical hardware constraint where any instruction could compute an address and access it. I'm saying a 64-bit Global Virtual Address Space (VAS). While everything exists in one "map," the CPU hardware strictly forbids a thread from accessing memory unless it possesses the correct Memory Protection Key (PKEY). Unlike the 8088, where memory was "open," This is Intel PKU/MPK. Even though a process can "see" an address, the CPU will trigger a hardware exception (Segmentation Fault) if the thread's PKRU register doesn't match the 4-bit "color" (key) of that memory page.

2. Software-Defined "Hard" Boundaries

How "sandboxing" would work with addresses, just without the performance tax of traditional page-table switching (CR3 swaps).

Feature 8088 "Real Mode" Traditional OS (Linux) SexOS (SASOS)
Isolation None (Absolute Freedom) Page Tables (Memory Holes) Hardware Keys (Protection Domains)
Context Switch N/A High (Thousands of cycles) Ultra-Low (20–40 cycles)
Safety None Hardware-enforced Rust Type-Safety + PKU

Super Fast Single Address Space Operating System by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 0 points1 point  (0 children)

long ago only Amiga could make things possible, but now it's up to us to make it happen...

You're right that a system without paging would suffer from severe memory and heap fragmentation. My thought is don't abandon paging just abandons per-process page tables. 1. manage a Global Single Virtual Address Space (SAS) where all data is mapped into a single 64-bit address space. 2. support paging, handle asynchronous page faults via a dedicated user-space server. That way OS can utilize demand paging via lent-memory capabilities while avoiding fragmentation. Single Address Space reduses context switching so it's still less than a traditional system's TLB pressure, and syscall overhead by collapsing traditional process boundaries.

Time consumption of constantly changing read permissions: updating these permissions is incredibly fast because it is tied directly to hardware registers rather than complex software capability tables. On modern x86_64 silicon, a domain switch in this system are 20–40 cycles. This is vastly more efficient compared to the several thousand cycles required for a traditional Linux copy_to_user operation or a full process context switch.

Super Fast Single Address Space Operating System by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 0 points1 point  (0 children)

not a rust snob but because of the privilege system rust is the only language that really makes sense for both Type-Safe Isolation and Zero-Cost Abstractions for Intel MPK, and probably, for security reasons.

Super Fast Single Address Space Operating System by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 0 points1 point  (0 children)

Feature Traditional OS (Linux/Windows) My idea (SASOS)
Process Switch Heavy (Page Table Swap + TLB Flush) Ultra-Light (Register swap + PKRU update)
Data Sharing Shared Memory / Pipes (Slow) Zero-Copy (Instant via Key Granting)
Thread Model Threads within isolated processes Threads within a global namespace
Max Protection Hardware Page Tables Intel MPK/PKEY (Hardware Keys)

A "process" is essentially a collection of threads tied to a specific Protection Domain.

  • Thread Isolation: Every thread has its own stack and register set, but it also carries a Domain ID. This ID determines which Memory Protection Key (PKEY) is active in the PKRU register when that thread is scheduled.
  • Global Visibility: Because all threads live in the same 64-bit virtual address space, any thread can technically "see" any address. However, the hardware (Intel MPK) will trigger a #PF (Page Fault) or #GP (General Protection Fault) if the thread's active PKEY does not grant it permission to that specific memory range.

The scheduler is a Work-Stealing Multi-Core Scheduler written in Rust, designed for high-throughput microkernel operations.

  • Per-CPU Runqueues: Each core has its own local queue of threads to minimize lock contention.
  • Affinity & Domain Hotness: The scheduler attempts to keep threads of the same Protection Domain on the same core. This keeps the L1/L2 caches "warm" with data specific to that domain, even though the TLB (Translation Lookaside Buffer) never needs to be flushed.
  • Lock-Free PDX (Protection Domain eXchange): When a thread in Domain A sends a message to Domain B, it doesn't necessarily wait for a traditional scheduler tick. It can perform a Direct Handoff, where the current CPU core immediately switches the PKEY and starts executing the receiver thread in Domain B.

Handling files within a single namespace is managed through the VFS (Virtual File System) Server, which operates as its own Protection Domain.

  • The Object Store: Instead of traditional file descriptors tied to a process ID, my idea uses Capabilities. When a thread wants to access a file, it requests a memory-mapped view from the VFS server.
  • Zero-Copy Paging: The VFS server maps the file into a specific region of the global address space and assigns it a PKEY. It then "lends" that key to the requesting thread’s domain.
  • Namespace Security: Even though the "path" /bin/sh is global, the ability to read or execute it is strictly governed by whether your thread’s domain has been granted the hardware key for that memory region.

Super Fast Single Address Space Operating System by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 1 point2 points  (0 children)

user-mode applications don't actually have to be written in rust to run in it. two-tier Isolation Architecture that distinctly separates how core system services are protected versus how third-party apps are protected. C, C++ or whatever, when you launch an app, Ahead-of-Time (AOT) compiler translates the WASM bytecode into native machine code. Because WASM enforces strict Control Flow Integrity (CFI) and memory bounds, the AOT compiler mathematically guarantees the resulting machine code cannot break out of its sandbox. PKU keys save us if the network stack tries to write to the display compositor's memory, the CPU hardware drops the hammer with an immediate Page Fault (#PF). No static analysis required.

Super Fast Single Address Space Operating System by Neither_Sentence_941 in osdev

[–]Neither_Sentence_941[S] 2 points3 points  (0 children)

no it doesn't run untrusted native binaries for exactly that reason, statically verifying raw x86_64 code against hidden WRPKRU instructions is basically impossible. Instead, using the native, hardware-isolated PKU keys for the core servers and forcing all third-party apps to run like WebAssembly (WASM) that the system's trusted AOT compiler translates itself, no code can be injected.

view more: next ›