bjorn3
4c4ab2de44
With this virtio-gpud no longer has to support getting deactivated at any time to hand back control to vesad. This makes it much easier to add many new features that a proper graphics driver is supposed to support. Be aware that virtio-gpud waits for the vsync on every flush request. Fbcond and orbital are not really happy about this right now and when something changes multiple times within a single frame, flush requests queue up, causing the ui to hang until all flush requests are finished. It is still possible to switch to another VT though which won't hang.
Drivers
This document covers the driver details.
Hardware Interfaces and Devices
- 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
- 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
- pcspkrd - PC speaker
- 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
Some drivers are work-in-progress and incomplete, read this tracking issue to verify.
System Interfaces
This section cover the interfaces used by Redox 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.
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@wbwriteback 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/eventscheme.
Contributing
Driver Design
A device driver on Redox is an user-space daemon that use system calls and schemes to work.
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).
Write a Driver
Datasheets are preferable, when they are freely available. Be aware that datasheets are often provided under a 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.
You can use the example driver or read the code of other drivers with the same type of your device.
Before testing your changes, be aware of this.
Driver References
If you want to reverse enginner the existing drivers, you can access the BSD code using these links: