commit | 2d60441e3c93f2324ce0671477b2810a44e13163 | [log] [tgz] |
---|---|---|
author | Yifei Teng <yifeit@google.com> | Wed Jan 16 15:12:07 2019 -0800 |
committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Mon Jan 28 20:56:59 2019 +0000 |
tree | 5d0e112e38fd2b76e1a3b2f547a50151f4a70cd2 | |
parent | 035a86e27393f613cd3dd68c56721d92f3afea93 [diff] |
[fidl][llcpp] Foundations for non-simple objects Notable optimizations: - In the callee-allocating flavor, automatically stack allocate when message size is < 512. Otherwise use C++ new. No VLAs. - No call to fidl_linearize when a type is completely inline. - No call to fidl_encode when the request type is inline and has no handles. (boring type) - No call to fidl_decode when the response type is inline and has no handles. (boring type) - No reference to coding table for boring types. In the future we could stop generating those coding tables altogether, reducing binary size. - All empty/zero-arg requests/responses share the same struct definition, which is essentially a fidl_message_header_t. Also added a script to easily regenerate all the llcpp binding code. The garnet CL used to generate the binding code is at: https://fuchsia-review.googlesource.com/c/garnet/+/239196 TEST: /boot/test/sys/fidl-llcpp-interop Change-Id: I4a31fe56d25504f3f76ea77c30b88a2f581a39df
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.