| commit | bfbcd87f2b51fd6ad4859035cadfa25668533395 | [log] [tgz] |
|---|---|---|
| author | Christopher Anderson <cja@google.com> | Tue Dec 04 14:45:30 2018 -0800 |
| committer | Christopher Anderson <cja@google.com> | Thu Jan 31 10:51:42 2019 -0800 |
| tree | e00473adbd2d2be4616f35c4505596473d46aca8 | |
| parent | fece664769513b209b0301c08c93df9086a26fbf [diff] |
[upci] Implement the upstream concept in userspace In kernel PCI, an upstream node was an interface for bridges and roots to allow for downstream allocation, and hooking scanned devices into the topology. In the user PCI world bus scanning and ownership will be handled by the top level Bus class, but we still need to have a hierarchy of allocators for device space downsteam. Unlike kernel PCI, this version of upstream implements two kinds of allocators: 1. Root allocators which allocate address space over the Pciroot protocol. This type is used by Root nodes. 2. Region allocators which allocate address space from their own region allocators which were allocated from the node upstream of them. Some method signatures have been included but are not implemented. These may go away in the future as the Bus driver interface is finalized. The bulk of the UpstreamNode interface related to downstream devices will be added back to the class as pci::Device objects are ported over to userspace to avoid CLs spanning thousands of lines. ZX-3146 Test: Compiled and ran upci, no regressions detected. Change-Id: I95dc56cab4ef6a1672c5eee7424a1e1995ba5f36
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.