tree: a1e304ee10ade6e0c280e8a35527298b1107bcfa [path history] [tgz]
  1. bin/
  2. doc/
  3. fidl/
  4. lib/
  5. scripts/
  6. testing/
  7. tests/
  8. BUILD.gn
  9. OWNERS
  10. README.md
  11. sysmgr_config.gni
src/sys/pkg/README.md

Contributing to the Software Delivery Stack

Overview

Software Delivery (SWD) Subsystems

Software Delivery Diagram

Binaries and their Locations

Updated: November 2019

Key Dependencies

Useful Debugging Tools

  • fidlcat: it’s strace, but for every IPC on the system, not just syscalls.
  • zxdb: Fuchsia’s debugger. Similar usage to gdb, and has Unicode support (emoji!). Doesn’t currently work well with golang, but works fine with Rust.
  • Inspect: Opt-in APIs for components to expose aspects of their state. Several portions of the SWD stack implement this, and more to come.
IDEs

VS Code seems to work pretty well. Follow the instructions here, including any language-specific instructions you find relevant; the Rust instructions are a good place to start.

Style Guide

Use the style guide appropriate for the language you’re in. The SWD stack is mostly in Rust and Go, which have strong opinions about style. All commits in those languages should be formatted with rustfmt and gofmt respectively, and most editors/IDEs have a mode in which you can run those commands when you save a file. Do so!

Setup

Fuchsia Setup

Read the Fuchsia Getting Started guide first

Most of the SWD stack is in the base image of fuchsia, so to get a swd stack working with tests, your build configuration is quite simple:

First tests


Tab 1 > fx set core.x64 --with //bundles:tests && fx build && fx serve Tab 2 > fx qemu -kN Tab 3 > fx run-test pkg-resolver-integration-tests # example of running the pkg-resolver integration tests

For further info on fx workflows: https://fuchsia.dev/fuchsia-src/development/workflows/fx

More general tests

If you’ve successfully run the above, you have a working Fuchsia system with the software delivery stack working.

You can discover more tests with by running fx list-packages on the host.

Common Workflows

Updating a base image to get a new version of pkg-resolver or pkgctl

To update the base of your fuchsia image, you can use fx update if you’re running on hardware which supports OTA. If you’re running under QEMU, you’ll need to just restart QEMU to get an updated base after a rebuild. Don’t worry, it’s fast.

Pulling down a new version of an external dependency

You’ll need to update that dependency’s vendored repository in //third_party. See the Rust documentation for examples.

Resolve a package and run a contained component

The package resolver is configured by default to resolve fuchsia.com to the local development host. To run a component in a package you’ve built locally, you can run something like fx shell run fuchsia-pkg://fuchsia.com/<package_name>#meta/<component_name>.cmx

TODO(wittrock): is there a global package repository we can use as a repo for this example?

FAQs

What’s the difference between amber and pkg-resolver?

We’re slowly migrating from (amber, pkgfs) to (pkg-resolver, pkg-cache, pkgfs). We expect this migration to be complete by the end of 2019.

How do I run a hosted package server?

See the instructions on running a package repository with pm

More information: