the Iconix operating system

Iconix is to be a microkernel-based OS, with a layer-cake model of system organization, heavy use of application-level virtualization, a robust IPC layer with a well-formed interface definition language, and API/UI cohesion with the help of well-defined interfaces. Applications for Iconix can be compiled in native code, or using a virtual machine language (I'm looking at wasm for this). Iconix runs its microkernel multiple times - either with virtualization and a hypervisor layer, or through asymmetric multiprocessing and homogeneous logical or hardware partitioning, or through heterogeneous, distributed remote process interfaces. This is to support each standard layer of the Iconix application and system security model.

The initial scope of development for the Iconix kernel and servicing stack, is UEFI PC x86-64. Further, I do intend for Iconix to have the ability to run in a compact, realtime mode, especially for embedded devices and small CPU's and small RAM configurations. Iconix, by itself, isn't meant to be restricted one implementation - in the likeness of TRON, which I am heavily inspired by - but rather as a standard series of interfaces to which compatible applications and system software, drivers and device servicing stack can be handled.

Iconix service processes communicate through well-defined interfaces, which are mapped by an interface definition file, written in IxIDL, a declarative statically-typed language with affordances to provide mappings between service processes and applications.

Iconix code is signed both at the program package level, and at the executable level. Strict W^X is enforced to system layer (Core, Device) processes, and applications are separated by either virtual or physical machine boundaries.

Iconix enforces a strict separation-of-systems principle in the organization of a running Iconix machine; however, this also creates potential security domain redundancy problems, as the Core needs to be able to manage the Base layer, and the Base layer needs to be able to communicate to the Core layer, even if they are on separate machines, even across the Internet.

Hence, Iconix interfaces that extend outside of a system boundary, will be proxied through an Interface Resolution Proxy. IRP, a service process which exists on either side of a cross-system interface, handles cryptographically ensuring the identity of a given machine and host process, wrapping messages and streams in encryption, and resolving destination processes to their target system or machine.

The Iconix GUI as far as pictographs, WIMP controls, widgets and visuals and the like, was going to be defined using a declarative, binary 3-dimensional animated vector language based on the Haiku HVIF standard.

Iconix's various runtime layers are alphabetized, six major layers in three groups: A/B, C/D, E/F.

A and B are paired, as the General system group, and run either on a high-performance applications processor, hardware application partition, or on a logically virtualized partition of their own, shared with the Core hypervisor; or multiple HV partitions, if different security domains, runtime considerations or application/hardware exclusivity comes into play.

This is the context in which the user application is running. Many Application layer domains will run on the same system, either under, or communicating with, the Base layer.

This is the runtime and subsystem components for the application layer. On Iconix applications, this will be a native Iconix kernel, scheduler, security domain/escalator, IPC, and job control. B and A can be the same code; in that case, an application is communicating directly to the Iconix core through Iconix IPC methods, and does not need an interposer or runtime. B can also host, and be, a different operating system, since it is an HV partition. Said operating system needs only implement IPC and some bootstrap handling for the Iconix core and establishing its application model, and this would typically be done through a driver.

C and D are also paired, as the Core System or Hypervisor system group, and will support one another through Core providing security/consent, and Device providing resources.

This handles local tasks, IPC and RPC, networking and resource management, job control and ensuring the background tasking context is satisfied and suspended, or activated and resumed as needed. C hosts several processes, as microkernel processes. These are “core modules”; technically, an Iconix application is an “application module”, as well, under the A layer.

This is where driver tasks, and direct hardware access is controlled. The bootloader is an Iconix module of class D, and its job is to load the init module, which further loads and runs the Iconix device model, BSP and system support data, and any hypervisor or supervisor for managing physical or logical subsystems.

This group consists of the Embedded and (optionally) Firmware layers. While technically part of a system running Iconix, they may or may not be Iconix-based themselves, and may or may not natively use Iconix interfaces to communicate and handle state transitions, bringup/teardown, power management and the like.

The difference between the two are largely semantic; E devices can be upgraded in-situ with code from a running Iconix system; F devices have permanent firmware, or hard-wired behavior and can only be reconfigured in a limited and closed set of states.

Iconix has five base Resource types: File, Global, Handle, Interface, and Job.

File resources are any static or temporary storage that exists as a single record of binary data.

Global resources are any environment variables or data, essentially, whether they are application-local or visible to the entire system.

Handle resources are a meta-resource - they provide exclusive access to a Resource, so as to avoid or prevent conflict.

Interface resources are any inter-process or inter-machine communication linkages, which are usually defined at compile-time.

Job resources are workers, services, processes or scheduled tasks, and may be instantiated through a Job Control Language.

Each interface has a type corresponding to which layer of the Iconix System it is interacting with - Application, Base, Core, Device or External. The standard interfaces are, vaguely in order of abstraction from the originating program or service:

KI provides essential machine-level, architecture-dependent interfaces to the program. This is usually not called directly, and is instead handled through higher-level interfaces. The KI is dynamically loaded into the program address space at runtime.

LI provides close-knit, non-public interfaces between worker processes of an application. These are not meant to be instantiated outside of the application, except when Instrumented, for debugging.

This is the standard inter-process machine-local interface type. Applications communicate between one another through MI, and MI can be machine-local or remote, but applications in RMI are considered part of the host system (for distributed/cluster computing, for instance.)

NI is essentially any foreign Iconix interface which is provided over the network, or the Internet. This is generally for application-specific data serialization between a network service and the local application.

OI is any interface type by which a human (or the automation thereof) would interact. OI is the underlying abstraction of the Iconix UI, which allows the same application to present to a command-line, TUI console, graphical user interface, audible user interface, or any affordances which humans may interact with a computer or its applications.

A PI is the interface which a programmer would be writing an application through. PI (specifically, the API) provides standard library calls through the Iconix inter-process mechanism, and is the expected (but not the only) way to instantiate and use external application libraries.

QI is an interface to provide scheduler, timing and futures/promises natively.

RI does management of interfaces, and handles the bringup and teardown of an Application, and its Resources such as worker processes.

(to be completed: Storage/Target.)

The SI is used for any data storage, either short- or long-term, access to application-local data and files, access to inter-application files, access to user data or user files, system data if necessary, and access to remote or network storage.

The TI is a special interface which is used for instrumentation, debugging and fitting of test harnesses and enables test-driven development at the interface level. TI would not exist to user applications unless they are being debugged.

See “Operating”; but specifically, UI handles the display and human interface/input device hardware abstraction layer, and its drivers.

ACPI is handled in the Device layer. It is handled first by the boot services (loader, init, init2, hvinit and hvpivot) And once hvpivoted, it is handled by D service Platform.ACPI

Platform.ACPI is ideally talking to smbios and ACPI/EFI firmware services through a limited shell layer, with a well-defined interface on it.

The Platform series of Layer D programs will have a restricted, “closed-shell” interface layer; all possible states and interfaces are to be well-defined and well-formed, and possibly applications of formal verification will come into play. All interactions accounted for, in other words. The system would have to really freak out to violate the conditions set forth.

Iconix does have some …. lineage about it, with me, too. I started work on it in 2000, at the age of eight. It was called the “Compu-TRON OS”, back then - and was intended to be an OS to match the uITRON, and later BTRON, specification.

Early on in the development history of Iconix, I wrote up a specification for an executable format for it. It was called LFAT, or “LinearFAT”, because that's exactly what it was - a FAT12 filesystem, containing the executable image components, linkages, and other sections, made read-only in FS attributes, and arranged linearly by block and non-fragmented/solid. If anything ran out of the 12-bit filesystem length, an MBR was prepended, and an additional FAT32 partition was added to support “LongLFAT”.

Iconix got its name from “a symbol is to an icon, as Symbolics is to Iconix”. I had some lisp-machine aspirations in the past.

more to follow