Schemes

The scheme, which takes its name from URI schemes, identifies the type of resource, and identifies the manager daemon responsible for that resource.

Within Redox, a scheme may be thought of in a few ways. It is all of these things:

• The type of a resource, such as "file", "NVMe drive", "TCP connection", etc. (Note that these are not valid scheme names, they are just given by way of example.)
• The starting point for locating the resource, i.e. it is the root of the path to the resource, which the system can then use in establishing a connection to the resource.
• A uniquely named service that is provided by some driver or daemon program, with the full path identifying a specific resource accessed via that service.

Scheme Daemons

A scheme is typically provided by a daemon. A daemon is a program that runs as a process in userspace; it is typically started by the system during boot. When the process starts, it registers with kernel using the name of the scheme that it manages.

Kernel vs. Userspace Schemes

A userspace scheme is implemented by a scheme daemon, described above. A kernel scheme is implemented within the kernel, and manages critical resources not easily managed with a userspace daemon. When possible, schemes should be implemented in userspace.

Accessing Resources

In order to provide "virtual file" behavior, schemes generally implement file-like operations. However, it is up to the scheme provider to determine what each file-like operation means. For example, seek to an SSD driver scheme might simply add to a file offset, but to a floppy disk controller scheme, it might cause the physical movement of disk read-write heads.

Typical scheme operations include:

• open - Create a handle (file descriptor) to a resource provided by the scheme. e.g. File::create("/scheme/tcp/127.0.0.1/3000") in a regular program would be converted by the kernel into open("127.0.0.1/3000") and sent to the "tcp" scheme provider. The "tcp" scheme provider would parse the name, establish a connection to Internet address "127.0.0.1", port "3000", and return a handle that represents that connection.
• read - get some data from the thing represented by the handle, normally consuming that data so the next read will return new data.
• write - send some data to the thing represented by the handle to be saved, sent or written.
• seek - change the logical location where the next read or write will occur. This may or may not cause some action by the scheme provider.

Schemes may choose to provide other standard operations, such as mkdir, but the meaning of the operation is up to the scheme. mkdir might create a directory entry, or it might create some type of substructure or container relevant to that particular scheme.

Some schemes implement fmap, which creates a memory-mapped area that is shared between the scheme resource and the scheme user. It allows direct memory operations on the resource, rather than reading and writing to a file descriptor. The most common use case for fmap is for a device driver to access the physical addresses of a memory-mapped device, using the memory: kernel scheme. It is also used for frame buffers in the graphics subsystem.

TODO add F-operations.

TODO Explain file-like vs. socket-like schemes.

Userspace Schemes

Redox creates user-space schemes during initialization, starting various daemon-style programs, each of which can provide one or more schemes.

Kernel Schemes

The kernel provides a small number of schemes in order to support userspace.

Scheme List

This section has all Redox schemes in a list format to improve organization, coordination and focus.

Userspace

• disk.*
• disk.live
• disk.usb-{id}+{port}-scsi
• logging
• initfs
• file
• network
• ip
• tcp
• udp
• icmp
• netcfg
• dns
• display.vesa
• display.virtio-gpu
• orbital
• pty
• audiorw
• audio
• usb.*
• pcspkr
• acpi
• input
• escalate
• chan
• shm
• log
• rand
• zero
• null

Kernel

• namespace
• user
• debug
• event
• irq
• pipe
• proc
• thisproc
• sys
• kernel.acpi
• memory
• time
• itimer
• serio