| commit | cd8b1496c666ec01d0ab408c3ab3e5355d807c32 | [log] [tgz] |
|---|---|---|
| author | Dustin Green <dustingreen@google.com> | Tue Nov 27 12:41:40 2018 -0800 |
| committer | Dustin Green <dustingreen@google.com> | Sat Jan 26 01:44:16 2019 +0000 |
| tree | 3743c40d59e4d1cd4c354b74391f34a36eda8281 | |
| parent | c5f32d54ec01d34df077ec52bba4ea0819e6c560 [diff] |
[sysmem] Sysmem as a Zircon driver. Because sysmem has a Zircon driver client (display driver) and a Zircon process client (virtcon), sysmem needs to be a Zircon driver. This CL creates the sysmem driver and gets it loaded for all boards. Future CLs will broker Zircon sysmem service requests to the driver, and will broker garnet+ sysmem service requests to the driver (via the Zircon service probably). Currently the only way to contact the sysmem driver is to talk to /dev/class/sysmem/000 directly. See previous paragraph for how that will change soon. Some of the interfaces are being updated. For now, the old sysmem remains in place and still implements the old interfaces, but we'll move those clients over soon. For now, sysmem runs in the platform bus driver devhost (or ACPI devhost) to permit sysmem to be contacted (soon) from devhost(s) that are children of the platform bus driver devhost (the only way to do driver-to-driver coms so far). In particular, the display driver will need to contact the sysmem driver. Tested: sysmem_tests Change-Id: I886ad89e6f166a136aa75f3f1128f71851928f0c
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.