Here are some general guidelines for patches to Zircon.
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 (
arm64) at every change. Use
fx multi bringup-cqso 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-codeto 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
- Before submitting documentation, make sure that the Markdown renders correctly.
When editing or adding
cmdlines, update the following:
- A list of kernel
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 int ZX_RESUME_NOT_HANDLED_DEPRECATION __attribute__((deprecated));
#define ZX_RESUME_NOT_HANDLED ((ZX_RESUME_NOT_HANDLED_DEPRECATION)(2))