| commit | f0bd7e172c2f2988f428e2036e49e6a026019e30 | [log] [tgz] |
|---|---|---|
| author | Mike Voydanoff <voydanoff@google.com> | Thu Aug 23 13:42:28 2018 -0700 |
| committer | Mike Voydanoff <voydanoff@google.com> | Fri Aug 24 06:04:05 2018 -0700 |
| tree | a223878245e327aae1a0c4579fa210a49745ee67 | |
| parent | db8c6033fcc2f354dc83088485db2a990c57e4a0 [diff] |
[dev][platform-bus] Use separate classes for platform devices and protocol implementation devices The class PlatformDevice in the platform bus driver was used for two purposes: 1) To implement platform devices, which run in separate devhosts. In this role the class did not need to implement the platform device protocol, but instead responded to proxied requests via the rxrpc callback from the PlatformProxy class in the other devhost. 2) To bind platform protocol implementation drivers, which run in the same devhost and do require a local platform device protocol implementation. To simplify the code, the PlatformDevice class implements use case 1), and a new class called ProtocolDevice implements use case 2. In addition, protocol implementation drivers are now given a restricted version of the platform bus protocol that disables pbus_device_add() and pbus_protocol_device_add(). There is no good use case for protocol implementation drivers to use these, so lets not allow it. TEST: manual testing on qemu, VIM2 and gauss. Change-Id: I2cbe1bf0d47fac00f37093275eee4db450776f78
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
A read-only mirror of the code is present at: https://github.com/fuchsia-mirror/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.