Resource Authority

R2Kernel resource authority controls whether a managed subsystem may use a host-local resource. Communication contracts describe data exchange. Resource claims describe access to CPU, network, field interfaces, devices, and frontend listeners.

Authority Model

flowchart LR PKG["Managed package instance"] --> CLAIM["Declared resource claim"] CLAIM --> AUTH["Host resource authority"] AUTH -->|"accepted"| RUN["Managed subsystem"] AUTH -->|"rejected"| FAIL["Launch failure with reason"]

The runtime evaluates claims before the managed subsystem depends on them. An accepted claim belongs to that package instance and is released when the managed process scope ends.

Resource Classes

Resource	Public behavior
CPU	requests affinity, scheduling, and isolation policy supported by the host
NIC	requests shared or exclusive access to selected network adapters
Link layer	requests bounded raw-link access for fieldbus gateways
CAN	requests access to selected SocketCAN interfaces
Serial and device nodes	requests access to selected host device outlets
Frontend listener	requests an instance-scoped listener for a package UI backend

The launch result reports which guarantees were applied and whether the host used a degraded fallback. Package code should not infer successful admission only from process startup.

Role Boundary

Gateway subsystems are the normal owners of hardware-facing claims. Component subsystems may request compute resources but should reach device-level hardware through gateway APIs. Compound subsystems may request a gateway directly when a platform-specific capability cannot be represented through an existing component. App subsystems consume platform capabilities and use the managed frontend path for package UI communication.

This is an architectural rule, not a Linux claim that arbitrary unmanaged programs cannot access the host. Product deployments must combine R2Kernel managed launch with appropriate operating-system and appliance policy.

Managed And Direct Execution

Managed package launch provides admission, ownership, cleanup, and runtime inspection. Direct execution from a shell remains useful during development, but it does not receive managed resource guarantees.

Product deployments should:

run product subsystems as managed packages
keep privileged helpers narrowly scoped
restrict protected devices through host policy
avoid broad user-group access to production hardware
restrict unmanaged shell and root access according to the product threat model

Observable Contract

Public documentation guarantees the following behavior.

claims are validated before managed use
conflicts are rejected with a diagnosable reason
accepted ownership is tied to one managed instance
process termination releases owned resources
launch status reports applied and degraded guarantees

The mechanism used to create or transfer an accepted host handle is a private runtime implementation detail.