4.5 KiB
Open Agila architecture direction
Status: original implementation, early boot and host-port milestone. This document separates implemented mechanisms from the proposed architecture.
Design references
OpenStep describes an OS-independent object-oriented application layer, including Foundation and Application Kit. Agila will define its own Ada/V framework contracts first; compatibility requires separately scoped conformance tests.
MINIX architecture separates a small privileged kernel from user-mode drivers and services, with explicit communication and authority checks. Open Agila's target is a small kernel and restartable services, not reuse of MINIX code or its exact IPC ABI.
The owner has a specific Open Amiga repository. Its URL/path, license, APIs, and tested targets are pending. No alternative project has been substituted, and no integration or compatibility claim is made.
Target structure
flowchart TD
Apps[Applications in V / Flying V and Ada] --> Frameworks[Agila application and foundation contracts]
Frameworks --> Services[User services: UI, files, network, audio]
Services --> IPC[Versioned IPC and scoped resource grants]
IPC --> Kernel[Ada kernel: address spaces, scheduling, IPC, interrupts]
Drivers[User device drivers] --> IPC
Kernel --> Hardware[CPU, memory and devices]
Only the bounded port mechanism and minimal boot path are implemented here. The service, syscall, framework, scheduler, and driver layers in this diagram are future work.
Current mechanism
Agila_Ports.Manager owns eight independent ports. Each holds four (sender, value) messages. Operations are non-blocking: a full queue returns Full; an empty queue returns Empty. Each port has an owner and at most one additional allowed sender. Only the owner can receive, grant, revoke, or close. Granting a different sender replaces the previous extra grant. Revocation prevents future sends; already queued messages remain queued.
The handle encodes a slot and generation. Closing clears queued data and advances the generation. A stale handle cannot address a reopened port. A slot retires at generation exhaustion instead of wrapping and making an ancient handle valid again. This is a reference-validity mechanism, not an unforgeable capability.
The host adapter accepts identity integers from its caller and stores a single global manager. It is deliberately single-threaded. A real syscall boundary must derive the caller from trusted scheduler state, validate user buffers, and synchronize shared state. An application that can choose its own identity can impersonate another caller in this demonstration.
Boot boundary
The BIOS/Multiboot entry starts in 32-bit mode, installs a GDT, creates temporary identity mappings for the first GiB, enables long mode, establishes a stack, and calls Ada. It assumes an x86-64-capable target. The mapping uses writable, executable 2 MiB pages and does not establish user/kernel protection.
The Ada entry verifies the Multiboot magic and exercises the port core before reporting success. The small C file only supplies compiler memory-copy/fill routines; it is not a memory allocator. Runtime checks remain enabled in host tests. The bare-metal build suppresses GNAT runtime checks because exception handling and the runtime are not yet ported. Explicit boot test conditions remain active. This is not a proof that every unchecked Ada execution is safe.
Language roles
- Ada: explicit kernel data structures and policies, bounded operations, contracts/tests, later scheduling and memory mechanisms.
- Standard V: host tools and initial application/service clients through documented interfaces.
- Flying V: a separate Agila application language, used only through its actual published SDK/toolchain contracts.
- Assembly and minimal C: necessary startup/ABI support, kept small and reviewed.
Future service interfaces should use versioned fixed-width fields and validated lengths rather than exposing Ada record layouts, V objects, host pointers, or compiler-specific enums across address spaces.
Evidence before claims
A host check demonstrates data-structure behavior under a host runtime. A QEMU boot check demonstrates a particular virtual machine and code path. Neither proves user-mode isolation, fault recovery, compatibility, or physical-device support. Those require the explicit tests in the roadmap.