Contributing to Zircon

Here are some general guidelines for patches to Zircon.

Process

  • Follow the process for Fuchsia patches outlined in Contribute changes.

  • Patches are handled through Gerrit Code Review.

  • Make sure Zircon is buildable for all major targets (x86-64, arm64) at every change. Use fx multi bringup-cq so that Zircon is buildable. For more information, see Building Zircon for all targets.

  • Avoid breaking the unit tests. Boot Zircon and run the tests to verify that they're all passing.

  • Avoid whitespace or style changes. Especially, do not mix style changes with patches that contain other changes, as style changes are often a distraction. Use fx format-code to format the code with the consistent style.

  • Avoid changes that touch multiple modules at once if possible. Most changes should be to a single library, driver, app, and so on.

Documentation for Zircon

Writing documentation is a great idea and is encouraged:

  • Documentation should be in Markdown files.
  • Zircon documentation is located in /docs/concepts/kernel.
  • Before submitting documentation, make sure that the Markdown renders correctly.

When editing or adding syscalls or cmdlines, update the following:

Notes

How to deprecate #define constants

You can create a deprecated typedef and have the constant definition cast to that type. The warning or error that is generated includes the name of the deprecated typedef.

typedef int ZX_RESUME_NOT_HANDLED_DEPRECATION __attribute__((deprecated));
#define ZX_RESUME_NOT_HANDLED ((ZX_RESUME_NOT_HANDLED_DEPRECATION)(2))