Change-Id: I32aaa13717667c8066e4370b419909258722cfea

Change-Id: Ib33df82650b9d96c66712bb3fc849c4188790b00

Also, mount blobfs at /blob rather than /blobstore.

Change-Id: I58ddded4440bed855eb8f8ffa26ed2bb319a9e85

Use ASCII quote character.

Change-Id: I7e1eb8583ced6a7fe83dcc6ae590757476b1bd89

ONB-33 #done

Change-Id: Iebd3be6d2755f30f33fd5714f8742e6c999807de

Makes more sense to have this instruction right before the first CMake
invocation.

Change-Id: I774f193e220c90d6ae9881718efd45207be7c1b3

Change-Id: I30b5384b66bf95bf79c777ed557f66befd02b4fd

Change-Id: Id421048b3a27d9611642c65f81c9a921a6ea0082

This document is a starting point for documenting the standards for code
in the SDK.

Change-Id: Ic0955bf9a24fcb0ffaec49c0f0bc516131a5c553

This allows for a development workflow that doesn't require
paving the device to get some types of new code on it.

Change-Id: Ib9439a3e3a1737f6e2ae674a38488dd976962737

Change-Id: I5746f9b737114598d7afe6930e98a000e6edb17f

Other fixes:
* Mark shell commands as bash or sh.
* Note that Zircon has a separate build system and link to its docs.
* Clarify relationship between fx and the lower level ways of doing a build.
* Link to a presentation giving an overview of GN.
* Reduce Heading levels by one.

ONB-29 #close

Change-Id: I3cf7785221421fa09b0c2fddd04e8095501cbc6e

TO-644

Change-Id: I4ac54b66aa9c8ef7bb366efc9fd93d6b04fa723b

TO-644

Change-Id: Ibddd73ebfa7a864a8f0fe94f7efbeac1ff2aa84e

Change-Id: I5961a4a04f8a3c768549bc0f3518622eaf5a89c9

Change-Id: I9c5a584520c795d59a40390df1860a29a3386722

TO-716 #done

Change-Id: Ibbe920cc9084bdae998771f9dddc6e2f5521d57a

TO-715 #done

Change-Id: I05846e458e67d0a4a15727b377727ec742ec6fe3

TO-644

Change-Id: Ib46ef106d204932672f0858399172c96c8757e5b

TO-644

Change-Id: Ibd58503dce6a6c14db3f7d93b67531c3ecd1d693

The clang+llvm-x86_64-linux path no longer exists.

Change-Id: I3cf70a9e060f47b856215712414ba98807938442

We don't actually use the -none triple format anywhere; we should be
using x86_64-fuchsia.

Change-Id: Iee64130caf9ffa46b43790decb9458c2fb7276b8

It moved into //topaz/shell.

Change-Id: Iba09c7a8b6f29333f20df6501348ad68d649e652

Thanks to Matthew Root for reporting this.

Change-Id: Iaca22fee88752279d9db1119623c4d3926a09527

Change-Id: I9a705764c92a33b15dcfb5a144b3e4d37a2e57f7

Change-Id: I445be04cb61a1a87609aa4a9d2ca8340e83ed701

Change-Id: I26ff172b0ebd37c2794c13316891676659e485a6

TO-690

Change-Id: Id2f08fea7e0607c630b42e1d5f8b987810922ead

This patch cleans up the entry-point(s) into Fuchsia documentation:

 - adds `development.md` as a top-level article to links covering
   development workflow, hw targets and coding conventions. Adds some
   missing links.
 - removes the bits about dev workflow from the Fuchsia book
 - makes README.md point to development.md and book.md, and makes it the
   target of "Home" in the navbar (and not book as before)

Change-Id: Ia437b6f016e51d2a340033128fe94d54bc636053

INTK-118 (tags for peridot)
INTK-121 (tags for topaz)
INTK-127 (tags for garnet)

Change-Id: Ie76b989635b8784c2f54639d4f4b4ac1ab26cbf0

Change-Id: I5b1c671634e2e53ed3da4f299f7b05ac53911377

Change-Id: Idea1d9eb2cbc534f92c5c5d0433c762e25b57f7c

The purpose of this doc is to explain concepts that I repeatedly explain
to Fuchsia developers, about defining our goals when writing tests and
figuring out how to write tests that achieve those goals.

The structure I'm going for is to first define an "ideal test" by
example. The ideal test is what we want tests to look like, and I
explain why. Then, I show how we can take a messy real-world Fuchsia
test and nudge it toward the ideal, based on an actual CL I wrote.

There's quite a bit of stuff that I left out of this doc because I don't
want it to be overloaded with "tips" or a list of "bad practices" versus
"good practices". My idea is that it's more effective to get a single
concept across and then let people work out for themselves how to work
with that concept. This also matches the way I've been working with
individual developers on test techniques: I rarely just say something
like, "This technique is bad". Rather, I point out ways in which a
certain technique succeeds/fails at our goals.

Questions for reviewers:
- Does the concept of "ideal test" make sense to you as a basis for
  reasoning about test strategy?
- Is the example ideal test a good one? Is it too simplified, or
  unnecessarily complex? Is it missing some important aspect that you
  think should be illustrated?
- Is the example real CL well-connected to the concepts?

Change-Id: I4d00bcbf03541f5fd0fa3bb0db40490694ff2a94

Change-Id: I13efec944dc5200a78c7a95d744e83f7700fd007

Change-Id: If89fb26ca50c7dec06eb24c7460674c3170d542e

Change-Id: I4e6e238e39fd34e0772cb1dfef3f4487d349ac36

Link targets suggested by mikejurka@.

Change-Id: Ie67dce2a5b5e7e82cdc212571769f1ef5294b688

Change-Id: I59755a86c74149622e81c01b9c524f4cce3bc50e

with abarth's recommendation

Change-Id: I0c380ecb58fa316d97163d86018ea9d0f5bb2465

Change-Id: Iae728cd237dc8b1fce6b74855ebae8eef534c41a