WIP docsite trunk

cobalt/site/docker/Dockerfile

@@ -13,11 +13,12 @@
 # limitations under the License.
 
 ARG FROM_IMAGE
-FROM ${FROM_IMAGE:-gcr.io/cloud-marketplace-containers/google/debian10}
+FROM ${FROM_IMAGE:-gcr.io/cloud-marketplace-containers/google/debian11}
 
 RUN apt update -qqy \
     && apt install -qqy --no-install-recommends \
         curl \
+        ca-certificates \
         doxygen \
         git \
         python3 \

cobalt/site/docs/gen/cobalt/doc/voice_search.md

@@ -26,15 +26,15 @@ on the SbMicrophone API as detailed above.
 
 In `starboard/linux/shared/soft_mic_platform_service.cc` there is an example
 stub implementation of the SoftMicPlatformService. Platforms can optionally
-implement this [CobaltPlatformService](https://cobalt.dev/gen/cobalt/doc/\
-platform_services.html) to specify if they support the `soft mic` and/or `hard mic`
-for voice search. The `soft mic` refers to the software activation of the microphone
-for voice search through the UI microphone button on the Youtube Web Application
-search page. The `hard mic` refers to hardware button activation of the microphone
-for voice search. Platforms can also specify the optional `micGesture`. This
-specifies the type of UI prompt the YouTube Web Application should display to guide
-the user to start voice search. The options include an empty or `null` value for no
-prompt, `"TAP"` for tap the `soft mic` and/or `hard mic` to start voice search, or
+implement this [CobaltPlatformService](platform_services.md) to specify if they
+support the `soft mic` and/or `hard mic` for voice search. The `soft mic` refers
+to the software activation of the microphone for voice search through the UI
+microphone button on the Youtube Web Application search page. The `hard mic`
+refers to hardware button activation of the microphone for voice search.
+Platforms can also specify the optional `micGesture`. This specifies the type of
+UI prompt the YouTube Web Application should display to guide the user to start
+voice search. The options include an empty or `null` value for no prompt,
+`"TAP"` for tap the `soft mic` and/or `hard mic` to start voice search, or
 `"HOLD"` for hold the `soft mic` and/or the `hard mic` to start voice search.
 
 The Web Application messages to the platform will be singular strings, encoded with

cobalt/site/docs/gen/starboard/build/doc/migrating_gyp_to_gn.md

@@ -266,8 +266,8 @@ This [document](./gn_migrate_stub_to_platform.md) outlines a step by step
 process for converting the stub platform's GN files to GN files that will be
 able to be built for your platform.
 
-[cobalt_porting_guide]: https://cobalt.dev/starboard/porting.html
-[dev_setup_linux]: https://cobalt.dev/development/setup-linux.html
+[cobalt_porting_guide]: https://developers.google.com/youtube/cobalt/docs/starboard/porting
+[dev_setup_linux]: https://developers.google.com/youtube/cobalt/docs/development/setup-linux
 [gn_check_tool]: https://cobalt.googlesource.com/third_party/gn/+/refs/heads/main/docs/reference.md#cmd_check
 [gn_doc_home]: https://cobalt.googlesource.com/third_party/gn/+/refs/heads/main/docs
 [gn_format_tool]: https://cobalt.googlesource.com/third_party/gn/+/refs/heads/main/docs/reference.md#cmd_format

cobalt/site/docs/gen/starboard/doc/c99.md

@@ -36,30 +36,38 @@ deprecated and eventually removed.
 ### <math.h>
 * acos
 * acosf
+* acosh
 * asin
 * asinf
+* asinh
 * atan
 * atan2
 * atan2f
 * atanf
+* atanh
 * cbrt
 * cbrtf
 * ceil
 * ceilf
 * cos
 * cosf
+* cosh
 * div
 * erf
 * erff
 * exp
 * expf
+* exp2
 * exp2f
 * fabs
+* fabsf
 * floor
 * floorf
+* fmaf
 * fmod
 * fmodf
 * frexp
+* ilogbf
 * isfinite
 * isnan
 * labs
@@ -80,17 +88,23 @@ deprecated and eventually removed.
 * nextafterf
 * pow
 * powf
+* remainder
 * round
 * roundf
 * scalbn
 * sin
 * sinf
+* sinh
 * sqrt
 * sqrtf
 * tan
 * tanf
+* tanh
 * trunc
 * truncf
+### <stdio.h>
+* sscanf
+* vsscanf
 ### <stdlib.h>
 * abs
 * atoi
@@ -134,3 +148,11 @@ deprecated and eventually removed.
 * wmemmove
 * wmemset
 * wcsncmp
+* snprintf
+* sprintf
+* vfwprintf
+* vsnprintf
+* vswprintf
+* ferror
+* fputwc
+* fwide

cobalt/site/docs/gen/starboard/doc/crash_handlers.md

@@ -35,7 +35,7 @@ const void* SbSystemGetExtension(const char* name) {
 }
 ```
 
-3. Calling the `third_party::crashpad::wrapper::InstallCrashpadHandler(bool start_at_crash)` hook
+3. Calling the `third_party::crashpad::wrapper::InstallCrashpadHandler()` hook
 directly after installing system crash handlers. On linux, for example, this
 could look like:
 
@@ -47,7 +47,8 @@ int main(int argc, char** argv) {
   starboard::shared::signal::InstallCrashSignalHandlers();
   starboard::shared::signal::InstallSuspendSignalHandlers();
 
-  third_party::crashpad::wrapper::InstallCrashpadHandler(true);
+  std::string ca_certificates_path = starboard::common::GetCACertificatesPath();
+  third_party::crashpad::wrapper::InstallCrashpadHandler(ca_certificates_path);
 
   int result = application.Run(argc, argv);
   ...

cobalt/site/docs/gen/starboard/doc/evergreen/cobalt_evergreen_overview.md

@@ -308,8 +308,8 @@ instructions available [here](cobalt_evergreen_reference_port_raspi2.md).
 
 1. Build the `crashpad_database_util` target and deploy it onto the device.
 ```
-$ cobalt/build/gn.py -p <partner_port_name> -c qa
-$ ninja -C out/<partner_port_name>_qa crashpad_database_util
+$ gn gen out/<partner_port_name>_qa --args='target_platform="<partner_port_name>" build_type="qa"'
+$ ninja -C out/<partner_port_name>_qa native_target/crashpad_database_util
 ```
 2. Remove the existing state for crashpad as it throttles uploads to 1 per hour:
 ```

cobalt/site/docs/gen/starboard/doc/evergreen/cobalt_evergreen_reference_port_raspi2.md

@@ -5,9 +5,8 @@ Book: /youtube/cobalt/_book.yaml
 
 ## Requirements
 
-*   Raspberry Pi 2 (image configured per
-    [instructions](https://cobalt.dev/development/setup-raspi.html) on
-    cobalt.dev)
+*   Raspberry Pi environment setup per
+    [instructions](https://developers.google.com/youtube/cobalt/docs/development/setup-raspi).
 
 ## Build instructions
 

cobalt/site/docs/gen/starboard/doc/style.md

@@ -123,9 +123,6 @@ the guidelines follow thusly as follows.
     casting the handle back and forth to the pointer type.
   * If a word in the name of a type is redundant with the module name, it is
     omitted.
-        * A monotonic time type in the Time module is `SbTimeMonotonic`, not
-          ~~`SbMonotonicTime`, `SbTimeMonotonicTime`, or
-          `SbTimeMonotonicSbTime`~~.
 
 ### Functions
 
@@ -191,10 +188,8 @@ namespace at the starboard repository root.
   * After the `k`, all constants have `Sb`, the Starboard namespace.
       * `kSb`
   * After `kSb`, all constants then have the module name.
-      * `kSbTime`
       * `kSbFile`
   * After `kSb<module>` comes the rest of the name of the constant.
-      * `kSbTimeMillisecond`
       * `kSbFileInvalid`
   * Enum entries are prefixed with the full name of the enum.
       * The enum `SbSystemDeviceType` contains entries like
@@ -238,14 +233,6 @@ namespace at the starboard repository root.
 
 ### Implementations
 
-  * Each API implementation should attempt to minimize other platform
-    assumptions, and should therefore use Starboard APIs to accomplish
-    platform-specific work unless directly related to the platform functionality
-    being implemented.
-        * For example, `SbFile` can use POSIX file I/O, because that what it is
-          abstracting, but it should use `SbMemoryAllocate` for any memory
-          allocations, because it might be used with a variety of `SbMemory`
-          implementations.
   * Whenever possible, each shared function implementation should be implemented
     in an individual file so as to maximize the chances of reuse between
     implementations.

cobalt/site/docs/gen/starboard/doc/versioning.md

@@ -59,8 +59,6 @@ error at compilation time.
 Generally Starboard applications will not support all versions of the Starboard
 API indefinitely. Starboard application owners may increment the minimum
 required Starboard version at their discretion.
-TBD: Timelines and communication around when an upcoming Cobalt release will
-require porters to implement a newer version of Starboard.
 
 ## Using new Starboard APIs from Starboard Applications
 
@@ -72,170 +70,11 @@ new functionality in Starboard applications if this evaluates to false.
 
 ## Adding and using new Starboard APIs
 
-### The "Experimental" Starboard Version
-
-At any given time, exactly one version of Starboard will be denoted as the
-"experimental" version, as defined by the `SB_EXPERIMENTAL_API_VERSION` macro in
-`starboard/configuration.h`. It is generally not recommended to declare support
-for this version. Any Starboard APIs defined in the experimental version are
-subject to change and API requirements could be added, removed, or changed at
-any time.
-
-### The "Release Candidate" Starboard Version
-
-At any given time, zero or more versions of Starboard will be denoted as the
-"release candidate" version, as defined by the
-`SB_RELEASE_CANDIDATE_API_VERSION` macro in `starboard/configuration.h`. The
-"release candidate" version is a set of API changes that have been considered
-and tested together. It is reasonable to port against this version, it has gone
-through some stabilization and may become frozen as it currently is. But, be
-aware that it is possible that minor incompatible changes may be made to this
-version if an unexpected situation arises. `SB_RELEASE_CANDIDATE_API_VERSION` is
-not defined if there is no "release candidate" version. Every API version
-greater than `SB_RELEASE_CANDIDATE_API_VERSION` but less than `SB_EXPERIMENTAL_API_VERSION` is also considered a release candidate.
 
 ### "Frozen" Starboard versions
 
-All Starboard versions that are less than the experimental and release candidate
-versions are considered frozen. Any Starboard APIs in a frozen version MUST not
-change.
-
-### Version Numbers, and how They Interrelate Numerically
-
-```
-frozen < release-candidate < experimental < future
-```
-
-As mentioned previously, a release candidate version may or may not exist at any
-given time.  When there is a release candate version, it follows the invariant
-above.
-
-### Life of a Starboard API
-
-New Starboard APIs should be defined in the experimental version.
-
-When introducing a new Starboard API (or modifying an existing one), a new
-feature version define should be created within the "Experimental Feature
-Defines" section of `starboard/configuration.h`, and set to
-`SB_EXPERIMENTAL_API_VERSION`. A well written comment should be added in front
-of the feature define that describes exactly what is introduced by the feature.
-In the comment, all new/modified/removed symbols should be identified, and all
-modified header files should be named.
-
-For example,
-
-```
-// in starboard/configuration.h
-
-#define SB_EXPERIMENTAL_API_VERSION 7
-
-#undef SB_RELEASE_CANDIDATE_API_VERSION
-
-// --- Experimental Feature Defines ------------------------------------------
-
-...
-
-// Introduce a new API in starboard/screensaver.h, which declares the following
-// functions for managing the platform's screensaver settings:
-//   SbScreensaverDisableScreensaver()
-//   SbScreensaverEnableScreensaver()
-// Additionally, a new event, kSbEventTypeScreensaverStarted, is introduced in
-// starboard/event.h.
-#define SB_SCREENSAVER_FEATURE_API_VERSION SB_EXPERIMENTAL_API_VERSION
-
-// Introduce a new API in starboard/new_functionality.h which declares the
-// function SbNewFunctionality().
-#define SB_MY_NEW_FEATURE_API_VERSION SB_EXPERIMENTAL_API_VERSION
-
-// Introduce another new API in starboard/still_in_development.h which
-// declares the function SbStillInDevelopment().
-#define SB_MY_OTHER_NEW_FEATURE_API_VERSION SB_EXPERIMENTAL_API_VERSION
-```
-
-When declaring the new interface, the following syntax should be used:
-
-```
-// starboard/new_functionality.h
-#if SB_API_VERSION >= SB_MY_NEW_FEATURE_API_VERSION
-void SbNewFunctionality();
-#endif
-```
-
-Starboard application features that use a new API must have a similar check:
-
-```
-// cobalt/new_feature.cc
-#if SB_API_VERSION >= SB_MY_NEW_FEATURE_API_VERSION
-void DoSomethingCool() {
-  SbNewFunctionality();
-}
-#endif
-```
-
-When promoting the experimental API version to be the release candidate API
-version, the previously undefined `SB_RELEASE_CANDIDATE_API_VERSION` is set to
-the current value of `SB_EXPERIMENTAL_API_VERSION`, and
-`SB_EXPERIMENTAL_API_VERSION` is then incremented by one. As a result,
-`SB_RELEASE_CANDIDATE_API_VERSION` on the master branch should always either be
-undefined, or `SB_EXPERIMENTAL_API_VERSION - 1`.
-
-One or more features are then moved from `SB_EXPERIMENTAL_API_VERSION` to
-`SB_RELEASE_CANDIDATE_API_VERSION`, and into the "Release Candidate Feature
-Defines" section of `starboard/configuration.h`. Some features may be left in
-experimental if they are not ready for release. The documentation comments of
-these features should be moved into the (newly created) section for the
-corresponding version in [starboard/CHANGELOG.md](../CHANGELOG.md).
-
-```
-// in starboard/configuration.h
-
-#define SB_EXPERIMENTAL_API_VERSION 8
-
-#define SB_RELEASE_CANDIDATE_API_VERSION 7
-
-// --- Experimental Feature Defines ------------------------------------------
-
-// Introduce another new API in starboard/still_in_development.h which
-// declares the function SbStillInDevelopment().
-#define SB_MY_OTHER_NEW_FEATURE_API_VERSION SB_EXPERIMENTAL_API_VERSION
-
-// --- Release Candidate Features Defines ------------------------------------
-
-#define SB_MY_NEW_FEATURE_API_VERSION SB_RELEASE_CANDIDATE_API_VERSION
-
-```
-
-When a release candidate branch is promoted to a full release, these new
-Starboard APIs will be irrevocably frozen to the value of
-`SB_RELEASE_CANDIDATE_API_VERSION`, and the release candidate version will be
-undefined. Additionally, the feature defines should be removed.
-
-```
-// starboard/new_functionality.h
-#if SB_API_VERSION >= 7
-void SbNewFunctionality();
-#endif
-
-// starboard/other_new_functionality.h
-#if SB_API_VERSION >= SB_MY_OTHER_NEW_FEATURE_API_VERSION
-void SbStillInDevelopment();
-#endif
-
-// starboard/configuration.h
-#define SB_EXPERIMENTAL_API_VERSION 8
-#undef SB_RELEASE_CANDIDATE_API_VERSION
-
-// cobalt/new_feature.cc
-#if SB_API_VERSION >= 7
-void DoSomethingCool() {
-  SbNewFunctionality();
-}
-#endif
-```
-
-Whoever increments the experimental version must ensure that stubs and reference
-platforms declare support for the new experimental version through their
-respective `SB_API_VERSION` macros.
+All Starboard versions that are less than the `SB_MAXIMUM_API_VERSION` version
+are considered frozen. Any Starboard APIs in a frozen version MUST not change.
 
 ### Communicating Starboard API changes to porters
 

cobalt/site/docs/reference/starboard/configuration-public.md

@@ -35,3 +35,5 @@ Book: /youtube/cobalt/_book.yaml
 | **`SB_IS_WCHAR_T_UTF32`**<br><br>Type detection for wchar_t.<br><br>The default value in the Stub implementation is `1` |
 | **`SB_IS_WCHAR_T_UTF16`**<br><br>The default value in the Stub implementation is `1` |
 | **`SB_IS_WCHAR_T_UNSIGNED`**<br><br>Chrome only defines this for ARMEL. Chrome has an exclusion for iOS here, we should too when we support iOS.<br><br>The default value in the Stub implementation is `1` |
+
+