diff --git a/source/clear-linux/concepts/autospec-about.rst b/source/clear-linux/concepts/autospec-about.rst index a314514c..6b1c3bc3 100644 --- a/source/clear-linux/concepts/autospec-about.rst +++ b/source/clear-linux/concepts/autospec-about.rst @@ -6,7 +6,7 @@ Autospec .. _incl-autospec-overview: Overview --------- +******** Whereas a standard RPM build process using ``rpmbuild`` requires a tarball and ``spec`` file to start, ``autospec`` only requires a tarball and package @@ -32,7 +32,7 @@ file. For a comprehensive list of control files, view the `autospec readme`_. -.. _incl-autospec-overview-end +.. _incl-autospec-overview-end: Control files are explained in Table 1. diff --git a/source/clear-linux/concepts/concepts.rst b/source/clear-linux/concepts/concepts.rst index dbb4b680..496e31e5 100644 --- a/source/clear-linux/concepts/concepts.rst +++ b/source/clear-linux/concepts/concepts.rst @@ -15,3 +15,4 @@ details relevant to the |CL| features. bundles-about autospec-about restart + telemetry-about diff --git a/source/clear-linux/concepts/figures/telemetry-about-1.png b/source/clear-linux/concepts/figures/telemetry-about-1.png new file mode 100644 index 00000000..37463254 Binary files /dev/null and b/source/clear-linux/concepts/figures/telemetry-about-1.png differ diff --git a/source/clear-linux/concepts/restart.rst b/source/clear-linux/concepts/restart.rst index 69a39964..f3faabb2 100644 --- a/source/clear-linux/concepts/restart.rst +++ b/source/clear-linux/concepts/restart.rst @@ -6,7 +6,8 @@ Restart system services after an OS update The software life cycle describes how software is created, developed, and deployed, and includes how to replace or update software. A good OS provides tools for the entire software life cycle. These tools must include -ways to remove software components properly when replaced with something else. +ways to remove software components properly when replaced with something +else. Most of the work on software update code in |CL| was focused on adding new software to the system. We recommended that users reboot their system once in @@ -32,9 +33,9 @@ solutions such as the following: * Ask the user to restart the OS. Both solutions are acceptable for many OSes. However, |CL| updates software -automatically and users do not see notices from the updater unless they review -the journal. |CL| requires a completely different solution, with the following -requirements: +automatically and users do not see notices from the updater unless they +review the journal. |CL| requires a completely different solution, with the +following requirements: * Eliminate the guesswork about what to restart and under what circumstances. * Cannot restart everything. Many service daemons do not support an automatic @@ -81,7 +82,7 @@ Figure 1: Invoke :command:`clr-service-restart`. :command:`clr-service-restart` implements a whitelist to identify which daemons can be restarted. The system administrator can customize the default -|CL| OS whitelist using :option:`allow` or :option:`disallow` options for +|CL| OS whitelist using *allow* or *disallow* options for restarting system services. When a software update occurs, :command:`clr-service-restart` consults the whitelist to see if a service daemon is allowed to be restarted or not. See the options section for @@ -91,32 +92,33 @@ details. Options for clr-service-restart ******************************* -The :option:`allow` option identifies a daemon to restart after an OS software +The *allow* option identifies a daemon to restart after an OS software update. The :command:`clr-service-restart` daemon creates a symlink in :file:`/etc/clr-service-restart` as a record. The example below tells -:command:`clr-service-restart` to restart the :option:`tallow` daemon after an +:command:`clr-service-restart` to restart the *tallow* daemon after an OS software update. .. code-block:: bash sudo clr-service-restart allow tallow.service -The :option:`disallow` option tells :command:`clr-service-restart` not to +The *disallow* option tells :command:`clr-service-restart` not to restart the specified daemon even if the OS defaults permit the daemon to be restarted. The :command:`clr-service-restart` daemon creates a symlink in -:file:`/etc/clr-service-restart` that points to :file:`/dev/null` as a record. -The example below tells :command:`clr-service-restart` not to restart the -:option:`rngd` daemon after an OS software update. +:file:`/etc/clr-service-restart` that points to :file:`/dev/null` as a +record. The example below tells :command:`clr-service-restart` not to +restart the *rngd* daemon after an OS software update. .. code-block:: bash sudo clr-service-restart disallow rngd -The :option:`default` option makes :command:`clr-service-restart` revert back -to the OS defaults and delete any symlink in :file:`/etc/clr-service-restart`. -The example below tells :command:`clr-service-restart` to restart -:option:`rngd` automatically again, because :option:`rngd` is whitelisted for -automatic service restarts by default in |CL|. +The *default* option makes :command:`clr-service-restart` revert back +to the OS defaults and delete any symlink +in :file:`/etc/clr-service-restart`. The example below +tells :command:`clr-service-restart` to restart *rngd* automatically again, +because *rngd* is whitelisted for automatic service restarts by default +in |CL|. .. code-block:: bash @@ -132,23 +134,24 @@ services are restarted after an OS software update. To monitor :command:`clr-service-restart`, use one or both options described below. -:option:`-n` +.. option:: -n -This option makes :command:`clr-service-restart` perform no restarts. Instead -it displays the services that could potentially be restarted. When used, -:command:`clr-service-restart` outputs a list of messages showing: + This option makes :command:`clr-service-restart` perform no restarts. + Instead it displays the services that could potentially be restarted. + When used, :command:`clr-service-restart` outputs a list of messages + showing: -* Which service needs a restart. -* What unit it is. -* Why it needs a restart. -* Which command is required to restart the unit. + * Which service needs a restart. + * What unit it is. + * Why it needs a restart. + * Which command is required to restart the unit. -:option:`-a` +.. option:: -a -This option makes :command:`clr-service-restart` consider all system services, -not only the ones that are whitelisted. Because the default whitelist in |CL| -is relatively short, you can use this option to restart all impacted services -when you log in on the system. + This option makes :command:`clr-service-restart` consider all system + services, not only the ones that are whitelisted. Because the default + whitelist in |CL| is relatively short, you can use this option to + restart all impacted services when you log in on the system. If you pass both options (:option:`-a` and :option:`-n`), :command:`clr-service-restart` displays a complete list of system services @@ -166,12 +169,14 @@ telemetry record and sends it to the optional |CL| telemetry service if both conditions below are met: * If a unit fails to automatically restart after an OS update. -* If that unit resides in the system location :file:`/usr/lib/systemd/system`. +* If that unit resides in the system + location :file:`/usr/lib/systemd/system`. If you do not install the |CL| telemetrics bundle, the data is discarded. If you install the telemetrics bundle and you opt to send telemetry, then the -system unit name is sent to the |CL| telemetry service. We evaluate the report -and update the whitelist to remove services that are not safe to restart. +system unit name is sent to the |CL| telemetry service. We evaluate the +report and update the whitelist to remove services that are not safe to +restart. Conclusion ********** diff --git a/source/clear-linux/concepts/swupd-about.rst b/source/clear-linux/concepts/swupd-about.rst index c3162de0..167cc215 100644 --- a/source/clear-linux/concepts/swupd-about.rst +++ b/source/clear-linux/concepts/swupd-about.rst @@ -129,7 +129,7 @@ system and its updates as the basis. Using this tool, system administrators can focus on the custom pieces their deployments require while staying on a controlled update stream. -To learn how to run an update of your system, visit our :ref:`update` page. +To learn how to run an update of your system, visit our :ref:`using swupd ` page. .. [1] The software update technology for Clear Linux* OS for Intel Architecture was first presented at the Linux Plumbers conference in 2012. diff --git a/source/clear-linux/concepts/telemetry-about.rst b/source/clear-linux/concepts/telemetry-about.rst new file mode 100644 index 00000000..b37e6d90 --- /dev/null +++ b/source/clear-linux/concepts/telemetry-about.rst @@ -0,0 +1,82 @@ +.. _telemetry-about: + +Telemetrics +########### + +One of the key features of |CLOSIA| is telemetry, which is used to +monitor system health. Telemetry enables developers to observe and proactively +address issues before end users are impacted. + +*Telemetrics* is a combination word made from: + +* *Telemetry* which is sensing and reporting data. +* *Analytics* which is using visualization and statistical inferencing to make + sense of the reported data. + +|CL| telemetry reports system-level debug/crash information using specialized probes. The +probes monitor system tasks such as :abbr:`swupd (software updater)`, kernel +oops, machine error checks, and BIOS error report table for unhandled hardware +failures. Telemetry enables real-time issue reporting to allow system +developers to quickly focus on an issue and monitor corrective actions. + +|CL| telemetry is fully customizable and can be used during software development +for debugging purposes. You can use **libtelemetry** in your code to create custom +telemetry records. You can also use **telem-record-gen** in script files or call +it from another program. + +Architecture +************ + +|CL| telemetry has two fundamental components, which are shown in figure 1: + +* Client: generates and delivers records to the backend server via the network. +* Backend: captures records sent from the client and displays the cumulative + content through a specialized interface. + + .. note:: + + If you want to capture your own records for analysis, you must set up + your own backend server. + +.. figure:: figures/telemetry-about-1.png + :scale: 75% + :alt: Clear Linux Telemetry Architecture. + + Figure 1: Clear Linux Telemetry Architecture. + +The telemetry client provides the front end of a complete telemetrics solution +and includes the following components: + +* **telemd**, a daemon that prepares the records to send to a telemetrics server or + spools the records on disk in case it cannot successfully deliver them. +* Probes that collect specific types of data from the operating system. +* **libtelemetry**, that telemetrics probes use to create telemetrics records and + send them to the telemd daemon for further processing. + +The telemetry backend provides the server-side component of a complete telemetrics solution and +consists of: + +* Nginx web server. +* Two Flask apps: + + * Collector, an ingestion web app for records received from telemetrics-client probes. + * TelemetryUI, a web app that exposes several views to visualize the telemetry data + and also provides a REST API to perform queries. + +* PostgreSQL as the underlying database server. + +The default telemetry backend server reports back to the |CL| development team +and is not viewable outside the Intel firewall. If you want to collect your +own records, then you must set up your own telemetry backend server. + +Next steps +********** + +To put this concept into practice, see the following resources: + +* :ref:`telemetry-enable` +* :ref:`telemetry-backend` +* `Telemetry feature description`_ + +.. _`Telemetry feature description`: + https://clearlinux.org/features/telemetry diff --git a/source/clear-linux/guides/maintenance/autospec.rst b/source/clear-linux/guides/maintenance/autospec.rst index 29ed5da7..dd4dd2d7 100644 --- a/source/clear-linux/guides/maintenance/autospec.rst +++ b/source/clear-linux/guides/maintenance/autospec.rst @@ -68,9 +68,9 @@ Create a RPM with autospec ************************** .. include:: ../../concepts/autospec-about.rst - :Start-after: incl-autospec-overview: + :start-after: incl-autospec-overview: :end-before: incl-autospec-overview-end: - + For a detailed explanation of how ``autospec`` works on |CL|, visit our :ref:`autospec-about` about page. For a general understanding of how RPMs work, we recommend visiting the `rpm website`_ or the diff --git a/source/clear-linux/guides/maintenance/bulk-provision.rst b/source/clear-linux/guides/maintenance/bulk-provision.rst index 60c57e0a..6badd952 100644 --- a/source/clear-linux/guides/maintenance/bulk-provision.rst +++ b/source/clear-linux/guides/maintenance/bulk-provision.rst @@ -92,7 +92,7 @@ Configuration within the web hosting directory of **ICIS**. The following example shows an Ister configuration file: - .. code-block:: json + .. code-block:: none template=http://192.168.1.1:60000/icis/static/ister/ister.json @@ -102,7 +102,7 @@ Configuration kernel parameter value. The following example shows an iPXE boot script with the ``isterconf`` parameter: - .. code-block:: json + .. code-block:: none #!ipxe kernel linux quiet init=/usr/lib/systemd/systemd-bootchart initcall_debug tsc=reliable no_timer_check noreplace-smp rw initrd=initrd isterconf=http://192.168.1.1:60000/icis/static/ister/ister.conf @@ -129,7 +129,7 @@ Configuration in the ``static`` directory within the web hosting directory of **ICIS**. The following example shows one such assignment: - .. code-block:: json + .. code-block:: none # MAC address,role 00:01:02:03:04:05,ciao @@ -138,7 +138,7 @@ Configuration :file:`config.txt` file, a default role for those MAC address may be defined as follows: - .. code-block:: json + .. code-block:: none # MAC address,role default,ciao diff --git a/source/clear-linux/guides/maintenance/mixer.rst b/source/clear-linux/guides/maintenance/mixer.rst index a2eaa0e4..b6f7cb3c 100644 --- a/source/clear-linux/guides/maintenance/mixer.rst +++ b/source/clear-linux/guides/maintenance/mixer.rst @@ -190,7 +190,7 @@ For example: Additionally, to build a mix with your own custom RPMs, use the optional -:option:`--local-rpms` flag, for example: +*--local-rpms* flag, for example: .. code-block:: bash @@ -203,7 +203,7 @@ the paths manually. For more information on using these directories or setting them up manually, see `Create or locate RPMs for the mix`_. If all upstream |CL| bundles will be part of the mix, you can easily add -them all during initialization with the optional :option:`--all-upstream` flag. For example: +them all during initialization with the optional *--all-upstream* flag. For example: .. code-block:: bash @@ -212,7 +212,7 @@ them all during initialization with the optional :option:`--all-upstream` flag. Finally, you may want to track the contents of your mixer workspace with a git repository. This is a great way to track changes to your mix's content or to revert to earlier versions if something goes wrong. Mixer can set this -up automatically with the optional :option:`--git` flag, for example: +up automatically with the optional *--git* flag, for example: .. code-block:: bash @@ -231,7 +231,7 @@ Edit builder.conf To configure the mixer tool, edit the :file:`builder.conf` as needed. The file :file:`builder.conf` is read automatically from the current -workspace directory. Use the :option:`--config` flag during initialization +workspace directory. Use the *--config* flag during initialization to specify an alternate path to the file as needed. The :file:`builder.conf` file has different sections, for example: @@ -417,7 +417,7 @@ bundles. When listing bundles with this command, mixer automatically recurses through the includes to show every single bundle in the mix. If you see an unexpected bundle in the list, that bundle is probably included -in another bundle. Use the :option:`--tree` flag to get a better view of how +in another bundle. Use the *--tree* flag to get a better view of how a bundle ended up in the mix, for example: .. code-block:: bash @@ -459,7 +459,7 @@ with the following command: mixer bundle list local Both the local and upstream :command:`bundle list` commands accept the -:option:`--tree` flag to show a visual representation of the inclusion relationships +*--tree* flag to show a visual representation of the inclusion relationships between the bundles in the mix. Edit the bundles in the mix @@ -561,7 +561,7 @@ This command removes `bundle1` from the mix bundle list stored in your :file:`mixbundles` file. By default, this command does not remove the bundle definition file from your local bundles. To completely remove a bundle, including its local bundle definition file, use the following command with -the :option:`--local` flag: +the *--local* flag: .. code-block:: bash @@ -569,7 +569,7 @@ the :option:`--local` flag: By default, removing a local bundle file with this command removes the bundle from the mix as well. To only remove the local bundle definition file, use -the following command with the :option:`--mix=false` flag: +the following command with the *--mix=false* flag: .. code-block:: bash @@ -599,7 +599,7 @@ can run this validation manually on `bundle1` with the following command: .. note:: This command can be useful in many circumstances. One example is when importing already-existing local bundles from other projects. -If you use the optional :option:`--strict` flag, the command additionally +If you use the optional *--strict* flag, the command additionally checks if the rest of the bundle header fields can be parsed, if the bundle header fields are non-empty, and if the bundle header ``Title`` field and the bundle filename match. Perform a strict validation of `bundle1` with the @@ -624,7 +624,7 @@ git commit after you modify the mix bundle list or edit a bundle definition file. All the :command:`mixer bundle` commands in the previous sections support an -optional :option:`--git` flag. This flag automatically applies a git commit +optional *--git* flag. This flag automatically applies a git commit when the command completes, for example: .. code-block:: bash @@ -654,7 +654,7 @@ chroots. We have added a new chroot-builder to the mixer tool itself. While this is currently an experimental feature, you should use the new chroot-builder. To use the new chroot-builder, use the following command with the -:option:`--new-chroots` flag: +*--new-chroots* flag: .. code-block:: bash @@ -681,7 +681,7 @@ By default, mixer uses the legacy `swupd-server` to generate the update content. However, we have built a new implementation into the mixer tool itself. While this is currently an experimental feature, you should use the new `swupd-server`. To use the the new `swupd-server`, use the following -command with the :option:`--new-swupd` flag: +command with the *--new-swupd* flag: .. code-block:: bash @@ -704,7 +704,7 @@ mix version to another, with the following command: The pack-maker generates all delta packs for the bundles changed from `PAST_VERSION` to `MIX_VERSION`. If your `STATE_DIR` is in a different -location, specify the location with the :option:`-S` flag. Mixer cannot +location, specify the location with the *-S* flag. Mixer cannot create delta packs for the first build because the update is from version 0. Version 0 implicitly has no content. Thus, mixer can generate no deltas. @@ -754,7 +754,7 @@ With the `ister` tool configured, build the image with the following command: Mixer automatically looks for the :file:`release-image-config.json` file, but you can freely choose the filename. To use a different name, simply pass the -:option:`--template` flag when creating your image, for example: +*--template* flag when creating your image, for example: .. code-block:: bash @@ -762,7 +762,7 @@ you can freely choose the filename. To use a different name, simply pass the By default, `ister` uses the format version of the build machine it runs on. Therefore, if the format you are building differs from the format of the |CL| -OS you are building on, you must use the :option:`--format ` +OS you are building on, you must use the *--format * flag. Find the current format version of your OS with the following command: .. code-block:: bash @@ -780,14 +780,14 @@ Increment the mix version number for the next mix with the following command: This command automatically updates the mix version stored in the :file:`mixversion` file, incrementing it by 10. To increment by a different -amount, use the :option:`--increment` flag, for example: +amount, use the *--increment* flag, for example: .. code-block:: bash mixer versions update --increment 100 Alternatively, to set the mix version to a specific value, use the -:option:`--mix-version` flag, for example: +*--mix-version* flag, for example: .. code-block:: bash @@ -802,7 +802,7 @@ If you have been tracking your workspace with git, you can restore the mix to an earlier state. However, be careful when "rewriting history" if you have published the mix content to users already. -Use the following command with the the :option:`--upstream-version` flag to +Use the following command with the the *--upstream-version* flag to update the upstream version of |CL| used as a base for the mix: .. code-block:: bash diff --git a/source/clear-linux/guides/maintenance/swupd-guide.rst b/source/clear-linux/guides/maintenance/swupd-guide.rst index db385152..e22a2695 100644 --- a/source/clear-linux/guides/maintenance/swupd-guide.rst +++ b/source/clear-linux/guides/maintenance/swupd-guide.rst @@ -7,7 +7,7 @@ Use swupd valid system updates and, if found, download and install them. It can also perform verification of the system software. -|CL| uses :ref:`bundles-about` as the base abstraction for +|CL| uses :ref:`bundles ` as the base abstraction for installing functionality on top of the core operating system. Use the `swupd` tool to install and remove bundles. diff --git a/source/clear-linux/guides/maintenance/telemetry-enable.rst b/source/clear-linux/guides/maintenance/telemetry-enable.rst index 3f6ed348..6d401226 100644 --- a/source/clear-linux/guides/maintenance/telemetry-enable.rst +++ b/source/clear-linux/guides/maintenance/telemetry-enable.rst @@ -5,11 +5,11 @@ Enable and disable telemetry in Clear Linux |CLOSIA| includes a telemetry solution as part of the OS that records events of interest and reports them back to the development team via the telemetrics -daemon, :command:`telemd`. This functionality is maintained in the -``telemetrics`` software bundle. +daemon, **telemd**. This functionality is maintained in the +**telemetrics** software bundle. .. note:: - The telemetry functionality adheres to `Intel's privacy policies`_ + The telemetry functionality adheres to `Intel privacy policies`_ regarding the collection and use of :abbr:`PII (Personally Identifiable Information)` and is open source. Specifically, no intentionally identifiable information about the user or system owner is collected. @@ -20,10 +20,10 @@ redirect where the records go if they wish to collect records for themselves. Install the telemetry software bundle ************************************* -During the initial installation of |CL| you are requested to join the +During the initial installation of |CL|, you are requested to join the stability enhancement program and allow |CLOSIA| to collect anonymous reports -to improve system stability. If you chose not to join this program at that -time then the telemetry software bundle is not added to your system. +to improve system stability. If you choose not to join this program, then the +telemetry software bundle is not added to your system. To install the telemetry bundle, enter the following command as either the root user or with :command:`sudo` privileges: @@ -104,9 +104,13 @@ To completely remove telemetrics from your system, use the command Additional resources ******************** -https://clearlinux.org/features/telemetry +* `Telemetry feature description`_ +* :ref:`Telemetry architecture` +* :ref:`telemetry-backend` +* https://github.com/clearlinux/telemetrics-client -https://github.com/clearlinux/telemetrics-client - -.. _`Intel's privacy policies`: +.. _`Intel privacy policies`: https://www.intel.com/content/www/us/en/privacy/intel-privacy-notice.html + +.. _`Telemetry feature description`: + https://clearlinux.org/features/telemetry diff --git a/source/clear-linux/reference/collaboration/documentation/documentation.rst b/source/clear-linux/reference/collaboration/documentation/documentation.rst index b16ce41b..ab615796 100644 --- a/source/clear-linux/reference/collaboration/documentation/documentation.rst +++ b/source/clear-linux/reference/collaboration/documentation/documentation.rst @@ -73,8 +73,7 @@ This style guide applies to the following technical content: We are always grateful to receive content contributions and are happy to help via our mailing list or our IRC channel, #clearlinux. If you have found a -problem with one of our documents, please file a bug report. Use our -:ref:`bug-report` to submit the bug. +problem with one of our documents, please file a `bug report`_. Tone and audience ***************** @@ -86,12 +85,12 @@ Remain professional in your writing and carry an undertone of cordiality, respect, and cooperation. Assume your audience has about the same level of technical understanding and -expertise as you did when you first started collaborating. Do not talk down to -our readers but do not assume they know everything about the subject. +expertise as you did when you first started collaborating. Do not talk down +to our readers but do not assume they know everything about the subject. Offer brief explanations or summaries of "common knowledge" if a significant portion of readers might benefit. -All contributions must follow our :ref:`code-of-conduct`. +All contributions must follow our `code of conduct`_. Methodology *********** @@ -126,7 +125,7 @@ decisions are explained in the respective section. This guide takes precedence over all other style guides in all cases. In cases where the guide does not address the issue at hand, please report the -issue to the `mailing list`_ using our :ref:`bug-report`. +issue to the `mailing list`_ using our `bug report`_. Use the Merriam-Webster's Collegiate Dictionary to determine correct spelling, hyphenation, and usage. @@ -136,3 +135,5 @@ spelling, hyphenation, and usage. .. _documentation section: https://clearlinux.org/documentation .. _Clear Linux documentation repository: https://github.com/clearlinux/clear-linux-documentation +.. _bug report: https://github.com/clearlinux/distribution/issues +.. _code of conduct: https://clearlinux.org/community/code-of-conduct diff --git a/source/clear-linux/reference/collaboration/documentation/inline.rst b/source/clear-linux/reference/collaboration/documentation/inline.rst index 2fb08380..2e516960 100644 --- a/source/clear-linux/reference/collaboration/documentation/inline.rst +++ b/source/clear-linux/reference/collaboration/documentation/inline.rst @@ -6,112 +6,157 @@ Inline Markup Sphinx supports a large number of inline markup elements called roles. The |CLOSIA| documentation encourages the use of as many roles as possible. Thus, you can use any additional roles supported by Sphinx -even if not listed here. Please refer to the `Sphinx Inline Markup`_ +not listed here. Please refer to the `Sphinx reStructuredText Markup`_ documentation for the full list of supported roles. The following markup is required in every instance unless otherwise -specified. Each item provides examples and a template for the correct use of -the roles. +specified. Each item provides a syntax example followed by the rendered +result. -* Use the `:abbr:` abbreviation role to define an acronym or an initialism. +Abbreviations + Use the `:abbr:` abbreviation role to define an acronym or an initialism. Add the abbreviation markup only once per file. After the abbreviation, the acronym can be used without further definition or markup. Do not use abbreviation markup on headings. - :abbr:`API (Application Program Interface)` + :: - Template: + :abbr:`API (Application Program Interface)` - ``:abbr:`TIA (This Is an Abbreviation)``` + .. parsed-literal:: -* Use the `:command:` role when the name of a specific command is used in a + :abbr:`API (Application Program Interface)` + +OS Commands + Use the `:command:` role when the name of a specific command is used in a paragraph for emphasis. Use the ``.. code-block::`` directive for fully actionable commands in a series of steps. - :command:`make` + :: - Template: + :command:`make` - ``:command:`command``` + .. parsed-literal:: -* Use the `:option:` role to emphasize the name of a command option - with or without its value. This markup is usually employed in - combination with the `:command:` role. For example: + :command:`make` - :option:`-f` - :option:`--all` - :option:`-o output.xsl` - The :command:`pandoc` command can be used without the :option:`-o` - option, creating an output file with the same name as the source - but a different extension. +Commandline Options + In most cases, use asterisks "*" to emphasize the name of a command + option. - Template: + :: - ``:option:`Option``` + Use the *-p* option to print the file. -* Use the `:file:` role to emphasize a filename or directory. Do not use the + .. parsed-literal:: + + Use the *-p* option to print the file. + + However, if you have defined an ``.. option::`` directive, you may + use the `:option:` role. Note that the result links back to the + option definition. + + .. code-block:: rest + + .. option: -o + + Description of the -o option + + The :command:`pandoc` command can be used without :option:`-o` + + .. option:: -o + + Description of the -o option + + .. parsed-literal:: + + The :command:`pandoc` command can be used without :option:`-o` + +Files + Use the `:file:` role to emphasize a filename or directory. Do not use the role inside a code-block but use it inside all notices that contain files or directories. Place variable parts of the path or filename in brackets `{}`. - :file:`collaboration.rst` :file:`doc/{user}/collaboration/figures` + .. code-block:: rest - Template: + :file:`collaboration.rst` - ``:file:`filename.ext` :file:`path/or/directory``` + :file:`doc/{user}/collaboration/figures` -* Use the `:guilabel:` role to emphasize elements of a graphic + .. parsed-literal:: + + :file:`collaboration.rst` + + :file:`doc/{user}/collaboration/figures` + +GUI Objects + Use the `:guilabel:` role to emphasize elements of a graphic user interface within a description. It replaces the use of quotes when referring to windows' names, button labels, options, or single menu elements. Always follow the marked element with the appropriate noun. For example: - In the :guilabel:`Tools` menu. - Press the :guilabel:`OK` button. - In the :guilabel:`Settings` window you find the :guilabel:`Hide - Content` option. + :: - Template: + In the :guilabel:`Tools` menu, click :guilabel:`settings`. - ``:guilabel:`UI-Label``` + .. parsed-literal:: -* Use the `:menuselection:` role to indicate the navigation through a menu + In the :guilabel:`Tools` menu, click :guilabel:`settings`. + +Menu Navigation + Use the `:menuselection:` role to indicate the navigation through a menu ending with a selection. Every `:menuselection:` element can have up to two menu steps before the selected item. If more than two steps are required, it can be combined with a `:guilabel:` or with another `:menuselection:` element. For example: - :menuselection:`File --> Save As --> PDF` - Go to :guilabel:`File` and select :menuselection:`Import --> Data - Base --> MySQL`. - Go to :menuselection:`Window --> View` and select :menuselection:` - Perspective --> Other --> C++` + :: - Template: + Go to :guilabel:`File` and select :menuselection:`Import --> Data Base --> MySQL`. - ``:menuselection:`1stMenu --> 2ndMenu --> Selection``` + Go to :menuselection:`Window --> View` and select :menuselection:`Perspective --> Other --> C++` -* Use the `:makevar:` role to emphasize the name of a Makefile variable. + .. parsed-literal:: + + Go to :guilabel:`File` and select :menuselection:`Import --> Data Base --> MySQL`. + + Go to :menuselection:`Window --> View` and select :menuselection:`Perspective --> Other --> C++` + +Makefile Variables + Use the `:makevar:` role to emphasize the name of a Makefile variable. The role can include only the name of the variable or the variable plus its value. - :makevar:`PLATFORM_CONFIG` - :makevar:`PLATFORM_CONFIG=basic_atom` + :: - Template: + :makevar:`PLATFORM_CONFIG` - ``:makevar:`VARIABLE``` + :makevar:`PLATFORM_CONFIG=basic_atom` -* Use the `:envvar:` role to emphasize the name of environment + .. parsed-literal:: + + :makevar:`PLATFORM_CONFIG` + + :makevar:`PLATFORM_CONFIG=basic_atom` + +Environment Variables + Use the `:envvar:` role to emphasize the name of environment variables. Just as with `:makevar:`, the markup can include only the name of the variable or the variable plus its value. - :envvar:`ZEPHYR_BASE` - :envvar:`QEMU_BIN_PATH=/usr/local/bin` + :: - Template: + :envvar:`ZEPHYR_BASE` + + :envvar:`QEMU_BIN_PATH=/usr/local/bin` - ``:envvar:`ENVIRONMENT_VARIABLE``` + .. parsed-literal:: -.. _Sphinx Inline Markup: - http://sphinx-doc.org/markup/inline.html#inline-markup + :envvar:`ZEPHYR_BASE` + + :envvar:`QEMU_BIN_PATH=/usr/local/bin` + +.. _Sphinx reStructuredText Markup: + http://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html \ No newline at end of file diff --git a/source/clear-linux/reference/reference.rst b/source/clear-linux/reference/reference.rst index b7ec6e29..15ee00ab 100644 --- a/source/clear-linux/reference/reference.rst +++ b/source/clear-linux/reference/reference.rst @@ -14,4 +14,5 @@ features. how-to-clear-overview collaboration/collaboration compatible-kernels - system-requirements \ No newline at end of file + system-requirements + image-types diff --git a/source/clear-linux/tutorials/azure.rst b/source/clear-linux/tutorials/azure.rst index 168fbcfd..397b7032 100644 --- a/source/clear-linux/tutorials/azure.rst +++ b/source/clear-linux/tutorials/azure.rst @@ -390,7 +390,7 @@ For this tutorial, we are using the |CL| Basic SKU for our VM. If you have already defined your public/private SSH key pair and they are stored in your :file:`$HOME/.ssh` directory, you do not need to - include the :option:`--generate-ssh-keys` option. + include the *--generate-ssh-keys* option. Your output from this command will look similar to this output, where [user] is your user name: diff --git a/source/clear-linux/tutorials/docker/docker.rst b/source/clear-linux/tutorials/docker/docker.rst index 6c6cae2a..91d1fa1d 100644 --- a/source/clear-linux/tutorials/docker/docker.rst +++ b/source/clear-linux/tutorials/docker/docker.rst @@ -141,12 +141,12 @@ an the official Docker image for nginx, an open source reverse proxy server. detailed :command:`docker run` switches and syntax, refer to the `Docker Documentation`_ . - * The :option:`--name` switch lets you provide a friendly name to + * The *--name* switch lets you provide a friendly name to target the container for future operations - * The :option:`-d` switch launches the container in the background + * The *-d* switch launches the container in the background - * The :option:`-p` switch allows the container's HTTP port (80) to be + * The *-p* switch allows the container's HTTP port (80) to be accessible from the Clear Linux host on port 8080 #. You can access the Welcome to Nginx! splash page running in the container diff --git a/source/clear-linux/tutorials/fmv.rst b/source/clear-linux/tutorials/fmv.rst index bd05bd3e..0ab93d84 100644 --- a/source/clear-linux/tutorials/fmv.rst +++ b/source/clear-linux/tutorials/fmv.rst @@ -184,7 +184,7 @@ You can see the multiple clones of the `foo` function: The cloned functions use AVX2 registers and vectorized instructions. To verify, enter the following commands: -.. code-block:: assembly +.. code-block:: asm vpaddd (%r8,%rax,1),%ymm0,%ymm0 vmovdqu %ymm0,(%rcx,%rax,1) @@ -213,53 +213,54 @@ To follow the same approach with a package like FFT, we must use the For example, the :file:`fftw-3.3.6-pl2/tools/fftw-wisdom.c.patch` file generates the following patches: -.. code-block:: git +.. code-block:: diff + :linenos: - 1 --- fftw-3.3.6-pl2/libbench2/verify-lib.c 2017-01-27 21:08:13.000000000 +0000 - 2 +++ fftw-3.3.6-pl2/libbench2/verify-lib.c~ 2017-09-27 17:49:21.913802006 +0000 - 3 @@ -33,6 +33,7 @@ - 4 - 5 double dmax(double x, double y) { return (x > y) ? x : y; } - 6 - 7 +__attribute__((target_clones("avx2","arch=atom","default"))) - 8 static double aerror(C *a, C *b, int n) - 9 { - 10 if (n > 0) { - 11 @@ -111,6 +112,7 @@ - 12 } - 13 - 14 /* make array hermitian */ - 15 +__attribute__((target_clones("avx2","arch=atom","default"))) - 16 void mkhermitian(C *A, int rank, const bench_iodim *dim, int stride) - 17 { - 18 if (rank == 0) - 19 @@ -148,6 +150,7 @@ - 20 } - 21 - 22 /* C = A + B */ - 23 +__attribute__((target_clones("avx2","arch=atom","default"))) - 24 void aadd(C *c, C *a, C *b, int n) - 25 { - 26 int i; - 27 @@ -159,6 +162,7 @@ - 28 } - 29 - 30 /* C = A - B */ - 31 +__attribute__((target_clones("avx2","arch=atom","default"))) - 32 void asub(C *c, C *a, C *b, int n) - 33 { - 34 int i; - 35 @@ -170,6 +174,7 @@ - 36 } - 37 - 38 /* B = rotate left A (complex) */ - 39 +__attribute__((target_clones("avx2","arch=atom","default"))) - 40 void arol(C *b, C *a, int n, int nb, int na) - 41 { - 42 int i, ib, ia; - 43 @@ -192,6 +197,7 @@ - 44 } - 45 } + --- fftw-3.3.6-pl2/libbench2/verify-lib.c 2017-01-27 21:08:13.000000000 +0000 + +++ fftw-3.3.6-pl2/libbench2/verify-lib.c~ 2017-09-27 17:49:21.913802006 +0000 + @@ -33,6 +33,7 @@ + + double dmax(double x, double y) { return (x > y) ? x : y; } + + +__attribute__((target_clones("avx2","arch=atom","default"))) + static double aerror(C *a, C *b, int n) + { + if (n > 0) { + @@ -111,6 +112,7 @@ + } + + /* make array hermitian */ + +__attribute__((target_clones("avx2","arch=atom","default"))) + void mkhermitian(C *A, int rank, const bench_iodim *dim, int stride) + { + if (rank == 0) + @@ -148,6 +150,7 @@ + } + + /* C = A + B */ + +__attribute__((target_clones("avx2","arch=atom","default"))) + void aadd(C *c, C *a, C *b, int n) + { + int i; + @@ -159,6 +162,7 @@ + } + + /* C = A - B */ + +__attribute__((target_clones("avx2","arch=atom","default"))) + void asub(C *c, C *a, C *b, int n) + { + int i; + @@ -170,6 +174,7 @@ + } + + /* B = rotate left A (complex) */ + +__attribute__((target_clones("avx2","arch=atom","default"))) + void arol(C *b, C *a, int n, int nb, int na) + { + int i, ib, ia; + @@ -192,6 +197,7 @@ + } + } With these patches, we can select where to apply the FMV technology making bringing architecture-based optimizations to application code even easier. diff --git a/source/clear-linux/tutorials/kata.rst b/source/clear-linux/tutorials/kata.rst index 1c6ef20b..aee38778 100644 --- a/source/clear-linux/tutorials/kata.rst +++ b/source/clear-linux/tutorials/kata.rst @@ -3,16 +3,16 @@ Install Kata Containers\* ######################### -This tutorial describes how to install, configure and run Kata Containers\* on -|CLOSIA|. Kata Containers is an open source project dedicated to the -development of a lightweight implementation of Virtual Machines (VMs) -offering the speed of containers and the security of VMs. +This tutorial describes how to install, configure, and run `Kata Containers`_ +on |CLOSIA|. Kata Containers is an open source project developing a +lightweight implementation of :abbr:`VMs (Virtual Machines)` that offer the +speed of containers and the security of VMs. Prerequisites ************* This tutorial assumes you have installed |CL| on your host system. -For detailed instructions on installing |CL| on a bare metal system, visit +For detailed instructions on installing |CL| on a bare metal system, follow the :ref:`bare metal installation tutorial`. If you have Clear Containers installed on your |CL| system, then follow the @@ -28,24 +28,23 @@ Install Kata Containers *********************** Kata Containers is included in the :file:`containers-virt` bundle. To install the -framework, enter: +framework, enter the following command: .. code-block:: bash sudo swupd bundle-add containers-virt -Configure Docker\* to use Kata Containers by default +Configure Docker\* to use Kata Containers by default. .. code-block:: bash sudo mkdir -p /etc/systemd/system/docker.service.d/ - cat <` +* :ref:`telemetry-enable` +* https://github.com/clearlinux/telemetrics-client +* https://github.com/clearlinux/telemetrics-backend .. _`Clear Linux telemetry backend server overview`: https://github.com/clearlinux/telemetrics-backend .. _`Intel privacy policies`: https://www.intel.com/content/www/us/en/privacy/intel-privacy-notice.html + +.. _`Telemetry feature description`: + https://clearlinux.org/features/telemetry diff --git a/source/conf.py b/source/conf.py index b9c7947b..448e260b 100644 --- a/source/conf.py +++ b/source/conf.py @@ -295,3 +295,6 @@ texinfo_documents = [ # If true, generates permalinks on the HTML output. html_add_permalinks = "" + +#suppresses warnings for options that aren't referenced +#suppress_warnings = ["ref.option"]