Improve, update and remove unnecessary READMEs
This commit is contained in:
Ribbon
@@ -4,30 +4,34 @@ Repository containing various system daemons, that are considered fundamental fo
|
||||
|
||||
You can see what each component does in the following list:
|
||||
|
||||
- audiod - Daemon used to process the sound drivers audio
|
||||
- bootstrap - First code that the kernel executes, responsible for spawning the init daemon
|
||||
- init - Daemon used to start most system components and programs
|
||||
- initfs - Filesystem with the necessary system components to run RedoxFS
|
||||
- ipcd - Daemon used for inter-process communication
|
||||
- logd - Daemon used to log system components and daemons
|
||||
- netstack - Daemon used for networking
|
||||
- ptyd - Daemon used for pseudo-terminal
|
||||
- ramfs - RAM filesystem
|
||||
- randd - Daemon used for random number generation
|
||||
- zerod - Daemon used to discard all writes and fill read buffers with zero
|
||||
- audiod : Daemon used to process the sound drivers audio
|
||||
- bootstrap : First code that the kernel executes, responsible for spawning the init daemon
|
||||
- daemon : Redox daemon library
|
||||
- drivers
|
||||
- init : Daemon used to start most system components and programs
|
||||
- initfs : Filesystem with the necessary system components to run RedoxFS
|
||||
- ipcd : Daemon used for inter-process communication
|
||||
- logd : Daemon used to log system components and daemons
|
||||
- netstack : Daemon used for networking
|
||||
- ptyd : Daemon used for pseudo-terminal
|
||||
- ramfs : RAM filesystem
|
||||
- randd : Daemon used for random number generation
|
||||
- zerod : Daemon used to discard all writes and fill read buffers with zero
|
||||
|
||||
## How To Contribute
|
||||
|
||||
To learn how to contribute to this system component you need to read the following document:
|
||||
To learn how to contribute you need to read the following document:
|
||||
|
||||
- [CONTRIBUTING.md](https://gitlab.redox-os.org/redox-os/redox/-/blob/master/CONTRIBUTING.md)
|
||||
|
||||
If you want to contribute to drivers read its [README](drivers/README.md)
|
||||
|
||||
## Development
|
||||
|
||||
To learn how to do development with this system component inside the Redox build system you need to read the [Build System](https://doc.redox-os.org/book/build-system-reference.html) and [Coding and Building](https://doc.redox-os.org/book/coding-and-building.html) pages.
|
||||
To learn how to do development with these system components inside the Redox build system you need to read the [Build System](https://doc.redox-os.org/book/build-system-reference.html) and [Coding and Building](https://doc.redox-os.org/book/coding-and-building.html) pages.
|
||||
|
||||
### How To Build
|
||||
|
||||
To build this system component you need to download the Redox build system, you can learn how to do it on the [Building Redox](https://doc.redox-os.org/book/podman-build.html) page.
|
||||
|
||||
This is necessary because they only work with cross-compilation to a Redox virtual machine, but you can do some testing from Linux.
|
||||
This is necessary because they only work with cross-compilation to a Redox virtual machine or real hardware, but you can do some testing from Linux.
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# audiod
|
||||
|
||||
Redox audio server
|
||||
@@ -1,10 +0,0 @@
|
||||
# bootstrap
|
||||
|
||||
First code that the kernel executes, responsible for spawning init.
|
||||
|
||||
## Funding - Process Manager (`src/procmgr.rs`)
|
||||
|
||||
The _Unix-style Signals and Process Management_ project is funded through [NGI Zero Core](https://nlnet.nl/core), a fund established by [NLnet](https://nlnet.nl) with financial support from the European Commission's [Next Generation Internet](https://ngi.eu) program. Learn more at the [NLnet project page](https://nlnet.nl/project/RedoxOS-Signals).
|
||||
|
||||
[<img src="https://nlnet.nl/logo/banner.png" alt="NLnet foundation logo" width="20%" />](https://nlnet.nl)
|
||||
[<img src="https://nlnet.nl/image/logos/NGI0_tag.svg" alt="NGI Zero Logo" width="20%" />](https://nlnet.nl/core)
|
||||
+103
-46
@@ -1,78 +1,135 @@
|
||||
# Drivers
|
||||
|
||||
This document covers the driver details.
|
||||
- [Libraries](#libraries)
|
||||
- [Services](#services)
|
||||
- [Hardware Interfaces](#hardware-interfaces)
|
||||
- [Devices](#devices)
|
||||
- [CPU](#cpu)
|
||||
- [Storage](#storage)
|
||||
- [Graphics](#graphics)
|
||||
- [Input](#input)
|
||||
- [Sound](#sound)
|
||||
- [Networking](#networking)
|
||||
- [Virtualization](#virtualization)
|
||||
- [System Interfaces](#system-interfaces)
|
||||
- [System Calls](#system-calls)
|
||||
- [Schemes](#schemes)
|
||||
- [Contribution Details](#contribution-details)
|
||||
|
||||
## Hardware Interfaces and Devices
|
||||
## Libraries
|
||||
|
||||
- ac97d - Realtek audio chipsets
|
||||
- acpid - ACPI interface
|
||||
- ahcid - SATA interface
|
||||
- alxd - Atheros ethernet
|
||||
- amlserde - a library to provide serialization/deserialization of the AML symbol table from ACPI
|
||||
- bgad - Bochs emulator and debugger
|
||||
- amlserde - Library to provide serialization/deserialization of the AML symbol table from ACPI
|
||||
- block-io-wrapper - Library used by other drivers
|
||||
- e1000d - Intel Gigabit ethernet
|
||||
- ided - IDE interface
|
||||
- ihdad - Intel HD Audio chipsets
|
||||
- inputd - Multiplexes input from multiple input drivers and provides that to Orbital
|
||||
- ixgbed - Intel 10 Gigabit ethernet
|
||||
- nvmed - NVMe interface
|
||||
- pcid - PCI interface with extensions for PCI Express
|
||||
- ps2d - PS/2 interface
|
||||
- rtl8139d - Realtek ethernet
|
||||
- rtl8168d - Realtek ethernet
|
||||
- sb16d - Sound Blaster audio
|
||||
- usbctl - USB control
|
||||
- usbhidd - USB HID
|
||||
- usbscsid - USB SCSI
|
||||
- vboxd - VirtualBox guest
|
||||
- vesad - VESA interface
|
||||
- virtio-blkd - VirtIO block device
|
||||
- virtio-core - VirtIO core
|
||||
- virtio-gpud - VirtIO GPU device
|
||||
- virtio-netd - VirtIO Network device
|
||||
- xhcid - xHCI USB controller
|
||||
- common - Library with shared driver code
|
||||
- executor - Library to run Rust futures and integrate the executor in an interrupt+queue model without a separated reactor thread
|
||||
- graphics/console-draw - Library with shared terminal drawing code
|
||||
- graphics/driver-graphics - Library with shared graphics code
|
||||
- graphics/graphics-ipc - Library with graphics IPC shared code
|
||||
- net/driver-network - Library with shared networking code
|
||||
- partitionlib - Library with MBR and GPT code
|
||||
- storage/driver-block - Library with shared storage code
|
||||
|
||||
Some drivers are work-in-progress and incomplete, read [this](https://gitlab.redox-os.org/redox-os/drivers/-/issues/41) tracking issue to verify.
|
||||
## Services
|
||||
|
||||
- graphics/fbbootlogd - Daemon for boot log drawing
|
||||
- graphics/fbcond - Terminal daemon
|
||||
- hwd - Handles the ACPI and DeviceTree booting
|
||||
- inputd - Multiplexes input from multiple input drivers and provides that to Orbital
|
||||
- pcid-spawner - Daemon for PCI device driver spawn
|
||||
- storage/lived - Daemon for live disk
|
||||
- redoxerd - Daemon that send/receive terminal text between the host system and QEMU
|
||||
|
||||
## Hardware Interfaces
|
||||
|
||||
- acpid - ACPI interface
|
||||
- pcid - PCI interface with PCI Express extensions
|
||||
|
||||
## Devices
|
||||
|
||||
### CPU
|
||||
|
||||
- rtcd - x86 real time clock
|
||||
|
||||
### Storage
|
||||
|
||||
- storage/ahcid - SATA interface
|
||||
- storage/bcm2835-sdhcid - Raspberry Pi 3B+ storage driver
|
||||
- storage/ided - IDE interface
|
||||
- storage/nvmed - NVMe interface
|
||||
- storage/virtio-blkd - VirtIO block device
|
||||
- usb/usbscsid - USB SCSI
|
||||
|
||||
### Graphics
|
||||
|
||||
- graphics/bgad - Bochs video driver
|
||||
- graphics/vesad - VESA interface
|
||||
- graphics/virtio-gpud - VirtIO GPU device
|
||||
|
||||
### Input
|
||||
|
||||
- input/ps2d - PS/2 interface
|
||||
- usb/usbhidd - USB HID
|
||||
- usb/usbctl - USB control
|
||||
|
||||
### Sound
|
||||
|
||||
- audio/ac97d - Realtek audio chipsets
|
||||
- audio/ihdad - Intel HD Audio chipsets
|
||||
- audio/sb16d - Sound Blaster audio
|
||||
|
||||
### Networking
|
||||
|
||||
- net/alxd - Qualcomm Atheros ethernet
|
||||
- net/e1000d - Intel Gigabit ethernet
|
||||
- net/ixgbed - Intel 10 Gigabit ethernet
|
||||
- net/rtl8139d, net/rtl8168d - Realtek ethernet
|
||||
- net/virtio-netd - VirtIO network
|
||||
|
||||
### Virtualization
|
||||
|
||||
- net/virtio-netd - VirtIO network device
|
||||
- vboxd - VirtualBox guest driver
|
||||
- virtio-core - VirtIO core
|
||||
- usb/xhcid - xHCI USB controller
|
||||
|
||||
Some drivers are work-in-progress and incomplete, read [this](https://gitlab.redox-os.org/redox-os/base/-/issues/56) tracking issue to verify.
|
||||
|
||||
## System Interfaces
|
||||
|
||||
This section cover the interfaces used by Redox drivers.
|
||||
This section explain the system interfaces used by drivers.
|
||||
|
||||
### System Calls
|
||||
|
||||
- `iopl` - syscall that sets the I/O privilege level. x86 has four privilege rings (0/1/2/3), of which the kernel runs in ring 0 and userspace in ring 3. IOPL can only be changed by the kernel, for obvious security reasons, and therefore the Redox kernel needs root to set it. It is unique for each process. Processes with IOPL=3 can access I/O ports, and the kernel can access them as well.
|
||||
- `iopl` : system call that sets the I/O privilege level. x86 has four privilege rings (0/1/2/3), of which the kernel runs in ring 0 and userspace in ring 3. IOPL can only be changed by the kernel, for obvious security reasons, and therefore the Redox kernel needs root to set it. It is unique for each process. Processes with IOPL=3 can access I/O ports, and the kernel can access them as well.
|
||||
|
||||
### Schemes
|
||||
|
||||
- `/scheme/memory/physical` - allows mapping physical memory frames to driver-accessible virtual memory pages, with various available memory types:
|
||||
- `/scheme/memory/physical`: default memory type (currently writeback)
|
||||
- `/scheme/memory/physical@wb` writeback cached memory
|
||||
- `/scheme/memory/physical@uc`: uncacheable memory
|
||||
- `/scheme/memory/physical@wc`: write-combining memory
|
||||
- `/scheme/irq` - allows getting events from interrupts. It is used primarily by listening for its file descriptors using the `/scheme/event` scheme.
|
||||
- `/scheme/memory/physical` : Allows mapping physical memory frames to driver-accessible virtual memory pages, with various available memory types:
|
||||
- `/scheme/memory/physical` : Default memory type (currently writeback)
|
||||
- `/scheme/memory/physical@wb` Writeback cached memory
|
||||
- `/scheme/memory/physical@uc` : Uncacheable memory
|
||||
- `/scheme/memory/physical@wc` : Write-combining memory
|
||||
- `/scheme/irq` : Allows getting events from interrupts. It is used primarily by listening for its file descriptors using the `/scheme/event` scheme.
|
||||
|
||||
## Contribution Details
|
||||
|
||||
### Driver Design
|
||||
|
||||
A device driver on Redox is an user-space daemon that use system calls and schemes to work.
|
||||
A device driver on Redox is an user-space daemon that use system calls and schemes to work, while operating systems with monolithic kernels drivers use internal kernel APIs instead of common program APIs.
|
||||
|
||||
For operating systems with monolithic kernels, drivers use internal kernel APIs instead of common program APIs.
|
||||
|
||||
If you want to port a driver from a monolithic OS to Redox you will need to rewrite the driver with reverse enginnering of the code logic, because the logic is adapted to internal kernel APIs (it's a hard task if the device is complex, datasheets are more easy).
|
||||
If you want to port a driver from a monolithic operating system to Redox you will need to rewrite the driver with reverse enginnering of the code logic, because the logic is adapted to internal kernel APIs (it's a hard task if the device is complex, datasheets are much more easy).
|
||||
|
||||
### Write a Driver
|
||||
|
||||
Datasheets are preferable (much more easy depending on device complexity), when they are freely available. Be aware that datasheets are often provided under a [Non-Disclosure Agreement](https://en.wikipedia.org/wiki/Non-disclosure_agreement) from hardware vendors, which can affect the ability to create an MIT-licensed driver.
|
||||
|
||||
If you don't have datasheets, we recommend you to do reverse-engineering of available C code on BSD drivers.
|
||||
If datasheets aren't available you need to do reverse-engineering of BSD or Linux drivers.
|
||||
|
||||
### Libraries
|
||||
|
||||
You should use the [redox-scheme](https://crates.io/crates/redox-scheme) and [redox_event](https://crates.io/crates/redox_event) crates to create your drivers, you can also read the [example driver](https://gitlab.redox-os.org/redox-os/exampled) or read the code of other drivers with the same type of your device.
|
||||
You should use the [redox-scheme](https://crates.io/crates/redox-scheme) and [redox_event](https://crates.io/crates/redox_event) libraries to create your drivers, you can also read the [example driver](https://gitlab.redox-os.org/redox-os/exampled) or read the code of other drivers with the same type of your device.
|
||||
|
||||
Before testing your changes, be aware of [this](https://doc.redox-os.org/book/coding-and-building.html#a-note-about-drivers).
|
||||
Before testing your changes be aware of [this](https://doc.redox-os.org/book/coding-and-building.html#how-to-update-initfs).
|
||||
|
||||
### References
|
||||
|
||||
@@ -96,4 +153,4 @@ To learn how to do development with this system component inside the Redox build
|
||||
|
||||
To build this system component you need to download the Redox build system, you can learn how to do it on the [Building Redox](https://doc.redox-os.org/book/podman-build.html) page.
|
||||
|
||||
This is necessary because they only work with cross-compilation to a Redox virtual machine, but you can do some testing from Linux.
|
||||
This is necessary because they only work with cross-compilation to a Redox virtual machine or real hardware, but you can do some testing from Linux.
|
||||
|
||||
@@ -1,14 +0,0 @@
|
||||
# RedoxOS init
|
||||
This repository contains the init system for RedoxOS.
|
||||
|
||||
Init is currently being rewritten to support a couple of behaviors that are helpful for running a configurable and robust system. These include:
|
||||
- Dependency relationships between services
|
||||
- Parallel service startup and shutdown
|
||||
- Configuration files for each service, including:
|
||||
- Dependencies
|
||||
- Methods
|
||||
- TODO: Users/Groups for services
|
||||
- TODO: Scheme namespaces for services
|
||||
- Service management
|
||||
- Enable and disable services
|
||||
- Restart failed services
|
||||
@@ -1,3 +0,0 @@
|
||||
# logd
|
||||
|
||||
Log daemon for collecting all log output.
|
||||
@@ -1,19 +0,0 @@
|
||||
# Redox OS userspace networking stack
|
||||
|
||||
This repository contains the networking stack for Redox OS. It makes use of [smoltcp](https://github.com/m-labs/smoltcp).
|
||||
|
||||
## How To Contribute
|
||||
|
||||
To learn how to contribute to this system component you need to read the following document:
|
||||
|
||||
- [CONTRIBUTING.md](https://gitlab.redox-os.org/redox-os/redox/-/blob/master/CONTRIBUTING.md)
|
||||
|
||||
## Development
|
||||
|
||||
To learn how to do development with this system component inside the Redox build system you need to read the [Build System](https://doc.redox-os.org/book/build-system-reference.html) and [Coding and Building](https://doc.redox-os.org/book/coding-and-building.html) pages.
|
||||
|
||||
### How To Build
|
||||
|
||||
To build this system component you need to download the Redox build system, you can learn how to do it on the [Building Redox](https://doc.redox-os.org/book/podman-build.html) page.
|
||||
|
||||
This is necessary because they only work with cross-compilation to a Redox virtual machine, but you can do some testing from Linux.
|
||||
@@ -1,19 +0,0 @@
|
||||
# ptyd
|
||||
|
||||
Pseudo-terminal daemon
|
||||
|
||||
## How To Contribute
|
||||
|
||||
To learn how to contribute to this system component you need to read the following document:
|
||||
|
||||
- [CONTRIBUTING.md](https://gitlab.redox-os.org/redox-os/redox/-/blob/master/CONTRIBUTING.md)
|
||||
|
||||
## Development
|
||||
|
||||
To learn how to do development with this system component inside the Redox build system you need to read the [Build System](https://doc.redox-os.org/book/build-system-reference.html) and [Coding and Building](https://doc.redox-os.org/book/coding-and-building.html) pages.
|
||||
|
||||
### How To Build
|
||||
|
||||
To build this system component you need to download the Redox build system, you can learn how to do it on the [Building Redox](https://doc.redox-os.org/book/podman-build.html) page.
|
||||
|
||||
This is necessary because they only work with cross-compilation to a Redox virtual machine, but you can do some testing from Linux.
|
||||
@@ -1,2 +0,0 @@
|
||||
# ramfs
|
||||
A mountable filesystem, which contents is stored in RAM. Useful for early logging, before `redoxfs` has been started. The `initfs:` scheme seems to lack read-write support, and thus this ramfs driver allows logs to be written in initfs drivers.
|
||||
@@ -1,3 +0,0 @@
|
||||
# randd
|
||||
|
||||
Random number generator daemon.
|
||||
@@ -1,3 +0,0 @@
|
||||
# zerod
|
||||
|
||||
A daemon that will discard all writes and always fill read buffers with zero.
|
||||
Reference in New Issue
Block a user