[ulib][ralloc] Add a cookie value to RegionAllocator::Region

A uint64_t cookie value has been added to the Region class. By doing it
in the Region class itself rather than the base ralloc_region_t it
allows for continued use of C style struct initializers with GetRegion.
Due to the const nature of returned regions from GetRegion, this cookie
is set immutably as an optional argument to GetRegion.  These changes
have the side effect of removing partiy between the C and C++ apis, but
only for the cookie. It is considered an acceptable cost to avoid all
callers using C style struct initialization needing to specify a default
cookie value.

The impact this change will have is an extra 8 bytes of memory per
region pulled out of an allocator. On a Pixelbook there are presently
~30 regions allocated at boot. This is miniscule compared to the benefit
the bookkeeping adds for clients of the library.

Test: region-alloc-test

Change-Id: I3f3eb65e990f94af58f71c6cc72fe36694632a13
3 files changed
tree: 22820a8a705546aad2f12cceb6be08326cacfe47
  1. .clang-format
  2. .clang-tidy
  3. .dir-locals.el
  4. .gitignore
  5. .travis.yml
  6. AUTHORS
  7. LICENSE
  8. MAINTAINERS
  9. PATENTS
  10. README.md
  11. bootloader/
  12. docs/
  13. kernel/
  14. make/
  15. makefile
  16. manifest/
  17. navbar.md
  18. prebuilt/
  19. public/
  20. scripts/
  21. system/
  22. third_party/
README.md

Zircon

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.