| commit | 601336d80ac66b3d46453239989158bc80ee8c5c | [log] [tgz] |
|---|---|---|
| author | James Tucker <raggi@google.com> | Fri Nov 30 17:53:04 2018 -0800 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Mon Dec 03 20:15:16 2018 +0000 |
| tree | a8b239cb37c31aae5835c28d74012d72f6c94c52 | |
| parent | 2c0251a2b361dc1cba485f46315283b56e102081 [diff] |
[tftp] track paving state through errors Always wait for the paver process to exit, regardless of state - executing the paver concurrently has undefined behavior. If the paver has received all data from the file transfer, capture the return code, and on non-zero, propagate that code back to bootserver. The layout of this patch is not ideal - it would be preferrable to track the state in the file_info field, however, the asynchrony and protocol result in a requirement to check for the error inside of "future" nodes in the state machine (i.e. on the next file, rather than the file that fails) under many conditions. The exit code must be checked at the first opportune moment, propagated and reset at that point. Test: manual: created a new fvm.sparse.blk containing only the first 50 blocks of a valid one. Old code continued after error, new code reports error to bootserver. Bug: ZX-2996 #comment zedboot reports paver errors to bootserver Change-Id: I9e191a5dbe0f744e7e86d00976330bfe6fe5d978
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.