diff --git a/source/clear-linux/clear-linux.rst b/source/clear-linux/clear-linux.rst index 2c4ffe42..b0c4258a 100644 --- a/source/clear-linux/clear-linux.rst +++ b/source/clear-linux/clear-linux.rst @@ -3,16 +3,23 @@ Clear Linux\* Project for Intel® Architecture ############################################# -Welcome to the |CLOSIA| documentation pages. Our documentation is split into -five sections: Get started, Concepts, Guides, Tutorials, and Reference. -Under :ref:`get-started`, you can find information about installing |CL| on -bare metal, in a virtual environment, or as a live image on a USB stick. Under -the :ref:`concepts` section, you can find detailed technical information about -the |CL| features. The :ref:`guides` section contains step-by-step -instructions to complete common tasks. The :ref:`tutorials` section contains -step-by-step instructions to complete the installation and configuration of -tools needed for a specific use case. Lastly, the :ref:`reference` section -contains information providing additional context or details. +Welcome to the |CLOSIA| documentation pages. Our documentation is divided +into five sections: + +* :ref:`get-started` Information about installing |CL| on + bare metal, in a virtual environment, or as a live image on a USB stick + +* :ref:`concepts` Detailed technical information about + |CL| features and what differentiates it from other |CL| distros + +* :ref:`guides` Step-by-step instructions on how to complete + common tasks that help you leverage |CL| native features + +* :ref:`tutorials` Step-by-step instructions for applying specific use + cases with |CL| that often involve third-party tools + +* :ref:`reference` Technical descriptions that provide context or + important details about |CL| .. toctree:: :maxdepth: 2 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/figures/telemetry-about/telemetry-about-1.png b/source/clear-linux/concepts/figures/telemetry-about-1.png similarity index 100% rename from source/clear-linux/concepts/figures/telemetry-about/telemetry-about-1.png rename to source/clear-linux/concepts/figures/telemetry-about-1.png 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/get-started/bare-metal-install/bare-metal-install.rst b/source/clear-linux/get-started/bare-metal-install/bare-metal-install.rst index 30e0967d..00c8cbe7 100644 --- a/source/clear-linux/get-started/bare-metal-install/bare-metal-install.rst +++ b/source/clear-linux/get-started/bare-metal-install/bare-metal-install.rst @@ -1,7 +1,7 @@ .. _bare-metal-install: -Install Clear Linux OS on bare metal -#################################### +Install Clear Linux OS on bare metal (automatic) +################################################ These instructions guide you through the installation of |CLOSIA| on bare metal using a bootable USB drive. diff --git a/source/clear-linux/get-started/bare-metal-install/bare-metal-manual-install.rst b/source/clear-linux/get-started/bare-metal-install/bare-metal-manual-install.rst index 99e48fae..8f750061 100644 --- a/source/clear-linux/get-started/bare-metal-install/bare-metal-manual-install.rst +++ b/source/clear-linux/get-started/bare-metal-install/bare-metal-manual-install.rst @@ -1,7 +1,7 @@ .. _bare-metal-manual-install: -Bare metal manual installation guide -#################################### +Install Clear Linux OS on bare metal (manual) +############################################# This section contains the steps for a |CL| manual installation. It picks up where the :ref:`bare-metal-install` left off. diff --git a/source/clear-linux/get-started/bare-metal-install/figures/bare-metal-install-8.png b/source/clear-linux/get-started/bare-metal-install/figures/bare-metal-install-8.png index 7d366096..0a0b3e25 100644 Binary files a/source/clear-linux/get-started/bare-metal-install/figures/bare-metal-install-8.png and b/source/clear-linux/get-started/bare-metal-install/figures/bare-metal-install-8.png differ diff --git a/source/clear-linux/get-started/bare-metal-install/figures/bare-metal-manual-install-9.png b/source/clear-linux/get-started/bare-metal-install/figures/bare-metal-manual-install-9.png index ed43c853..4b7fa392 100644 Binary files a/source/clear-linux/get-started/bare-metal-install/figures/bare-metal-manual-install-9.png and b/source/clear-linux/get-started/bare-metal-install/figures/bare-metal-manual-install-9.png differ diff --git a/source/clear-linux/get-started/bare-metal-install/figures/cgdisk-manual-install-11.png b/source/clear-linux/get-started/bare-metal-install/figures/cgdisk-manual-install-11.png index 91a2d13d..3e73dc50 100644 Binary files a/source/clear-linux/get-started/bare-metal-install/figures/cgdisk-manual-install-11.png and b/source/clear-linux/get-started/bare-metal-install/figures/cgdisk-manual-install-11.png differ diff --git a/source/clear-linux/guides/guides.rst b/source/clear-linux/guides/guides.rst index e8f20f8f..f2c65575 100644 --- a/source/clear-linux/guides/guides.rst +++ b/source/clear-linux/guides/guides.rst @@ -3,6 +3,13 @@ Guides ###### +Our Guides: + +* Provide a critical, fundamental understanding of |CL| features +* Show you how to leverage the full feature set of |CL| +* Enhance your productivity when using |CL| + + The following guides provide step-by-step instructions for tasks that come after completing the |CL| :ref:`installation `. 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/developer-workstation.rst b/source/clear-linux/guides/maintenance/developer-workstation.rst new file mode 100644 index 00000000..d408aebf --- /dev/null +++ b/source/clear-linux/guides/maintenance/developer-workstation.rst @@ -0,0 +1,111 @@ +.. _developer-workstation: + +Developer Workstation +##################### + +Overview +******** + +*Developer Workstation* helps you find the :ref:`bundles-about` you need to +start your |CL| development project. + +Before continuing, we recommend that you learn how to use +:ref:`swupd `. Visit our :ref:`swupd-about` page to understand +how |CL| simplifies software versioning compared to other Linux\* +distributions. + +Workstation Setup +================= + +This guide helps you understand the minimum bundles required to get started. +After installing them, you can add more bundles relevant to your use case. +To run any process required for Clear Linux development, you can add the +large bundle :ref:`*os-clr-on-clr* `. However, given how +many packages this bundle contains, you may want instead to deploy a leaner +OS with only those bundles relevant to your project. Developer Workstation +responds to this need. + +Use Table 1, *Clear Linux Developer Profiles*, to identify the *minimum +required bundles* to get started developing based on your role or project. +While your role may not neatly fit in one of these categories, consider using Table 1 as a starting point. + +.. list-table:: **Table 1. Clear Linux Developer Profiles** + :widths: 20, 20, 20, 20 + :header-rows: 1 + + * - Clear Linux Bundle + - *Internet of Things (IoT)* + - *System Administrator* + - *Client/Cloud/Web Developer* + + * - `editors` + - ✓ + - ✓ + - ✓ + + * - `network-basic` + - ✓ + - ✓ + - ✓ + + * - `openssh-server` + - ✓ + - ✓ + - ✓ + + * - `webserver-basic` + - + - ✓ + - ✓ + + * - `application-server` + - + - ✓ + - ✓ + + * - `database-basic` + - + - ✓ + - ✓ + + * - `desktop-autostart` + - ✓ + - ✓ + - ✓ + + * - `dev-utils` + - + - + - ✓ + +`swupd` search +============== + +We recommend trying out :ref:`swupd search `, to learn the +commands to search for and add bundles relevant to your project. + +:ref:`swupd-search` shows you how to: + +* Use `swupd` to search for bundles +* Use `swupd` to add bundles + +Core Concepts +============= + +We recommend that you understand these core concepts in |CL| *before* +developing your project. + +* :ref:`Bundles ` +* :ref:`Software update ` +* :ref:`Mixer ` +* :ref:`Autospec ` + +Other resources for developers +----------------------------------- + +* `Developer Tooling Framework for Clear Linux`_ +* `Clear Linux Bundles`_ + +.. _Clear Linux Bundles: https://github.com/clearlinux/clr-bundles + +.. _Developer Tooling Framework for Clear Linux: https://github.com/clearlinux/common diff --git a/source/clear-linux/guides/maintenance/maintenance.rst b/source/clear-linux/guides/maintenance/maintenance.rst index b65cadbe..09737c90 100644 --- a/source/clear-linux/guides/maintenance/maintenance.rst +++ b/source/clear-linux/guides/maintenance/maintenance.rst @@ -9,6 +9,8 @@ maintaining |CLOSIA| after :ref:`installation ` is completed. .. toctree:: :maxdepth: 2 + developer-workstation + swupd-search enable-user-space swupd-guide bulk-provision 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/swupd-search.rst b/source/clear-linux/guides/maintenance/swupd-search.rst new file mode 100644 index 00000000..2a066451 --- /dev/null +++ b/source/clear-linux/guides/maintenance/swupd-search.rst @@ -0,0 +1,144 @@ +.. _swupd-search: + +Use swupd search to find bundles +################################ + +.. contents:: + :local: + :depth: 2 + +This document shows you how to use `swupd search` to find and add +bundles. + +Assumptions +*********** + +This guide assumes you: + +* Possess a basic knowledge of :ref:`swupd ` +* Understand :ref:`how swupd differs ` from + other Linux\* distributions +* May use :ref:`mixer` to build your own |CL| OS + +How do I search for a bundle? +***************************** + +Use `swupd search` to locate the bundle where the application binary exists. + +Example: Kata Containers +======================== + +Containers have revolutionized the way we manage cloud infrastructure. +Traditional containers often share the same OS kernel, which raises +security concerns. Instead, with Kata Containers, each container has its own +kernel instance and runs on its own :abbr:`Virtual Machine (VM)`. Whether you're running 3 or 300 nodes on your cluster, Kata Containers provide a +lightweight, fast, and secure option for app/container management. + +In |CL|, you only need to add `this bundle`_ to use `Kata Containers`_: +`containers-virt`. Also, check out our tutorial: :ref:`kata`. + +We need to find *kata* containers in a bundle. How do we search for it? + +#. Enter :command:`swupd search`, followed by 'kata' as the search term: + + .. code-block:: bash + + sudo swupd search kata + + .. note:: + + `swupd search` downloads |CL| manifest data and searches for + matching paths. Enter only one term, or hyphenated term, per + search. Use the command :command:`man swupd` to learn more. + +#. Alternatively, if you want to search binaries only, add the `-b` + flag: + + .. code-block:: bash + + sudo swupd search -b kata + + .. note:: + + `-b` flag, or `--binary`, means: Restrict search to program binary paths. Omit this flag if you want a larger scope of search results. + + Only the base bundle is returned. In |CL|, *bundles* can contain + other *bundles* via `includes`. For more details, see `Bundle Definition Files`_ and its subdirectory *bundles*. + + If your search does not produce results on a specific term when using + the `-b` flag, abbreviate the search term. For example, if you search + for *kubernetes* and it does not show results, instead abbreviate the + term to *kube* to show results. + +#. Optionally, you can review our `bundles`_ or individual `packages`_ + +#. Using `sudo swupd search -b kata` shows a match for our use case. + + .. code-block:: console + + Bundle containers-virt (834 MB to install) + /usr/bin/kata-virtfs-lite-proxy-helper + /usr/bin/kata-runtime + /usr/bin/kata-qemu-lite-system-x86_64 + /usr/bin/kata-qemu-lite-pr-helper + /usr/bin/kata-qemu-lite-ga + /usr/bin/kata-collect-data.sh + + .. note:: + + If the bundle is already installed, *[installed]* appears in search results. If this doesn't apppear, the bundle needs to be installed. + +#. Add the bundle `containers-virt`: + + .. code-block:: bash + + sudo swupd bundle-add containers-virt + + .. note:: + + To add multiple bundles simply add a space followed by the bundle name. + +#. When prompted, enter your password. + +#. Upon successful installation, your console should show similar data: + + .. code-block:: console + + Downloading packs... + + Extracting containers-virt pack for version 24430 + ...50% + Extracting kernel-container pack for version 24430 + ...100% + Starting download of remaining update content. This may take a while... + ...100% + Finishing download of update content... + Installing bundle(s) files... + ...100% + Calling post-update helper scripts. + Successfully installed 1 bundle + +FAQ +=== + +Find answers to these common questions: + +* How do I install and *use* :ref:`Kata Containers ` on |CL|? + +* How do I :ref:`kata_migration`? + +* How do I show all :ref:`bundles available `? + +* How do I :ref:`update swupd`? + +* How do I :ref:`remove bundles`? + +.. _Kata Containers: https://clearlinux.org/blogs/clear-linux-os-announces-support-kata-containers + +.. _this bundle: https://github.com/clearlinux/clr-bundles/blob/master/bundles/containers-virt + +.. _Bundle Definition Files: https://github.com/clearlinux/clr-bundles + + .. _bundles: https://github.com/clearlinux/clr-bundles/tree/master/bundles + + .. _packages: https://github.com/clearlinux/clr-bundles/blob/master/packages diff --git a/source/clear-linux/reference/collaboration/documentation/cross.rst b/source/clear-linux/reference/collaboration/documentation/cross.rst index 8b4d726d..4f5efc2a 100644 --- a/source/clear-linux/reference/collaboration/documentation/cross.rst +++ b/source/clear-linux/reference/collaboration/documentation/cross.rst @@ -15,16 +15,18 @@ Internal cross-references An internal cross-reference is a reference to a location within the |CLOSIA| documentation. Use explicit markup labels and the ``:ref:`` role to create cross references to headings, figures, and code examples as needed. Every -file must have a label before the title identical to the file's name in order -to be able to add cross-references without having to open the file. +file must have a label before the title, which is identical to the file's +name, in order to be be cross-referenced within the entire documentation. -The labels' naming conventions are: +Labels' naming conventions: + +* Ensure the label is unique throughout the documentation * Use only full words. * Use \- to link multiple words. -* Use only as many words as necessary to ensure the label is unique. +* Use only as many words as necessary. These are some examples of proper labels: @@ -81,7 +83,8 @@ This creates a link to the :ref:`label-of-target` using the text of the heading. This creates a link to the :ref:`target ` using the word -'target' instead of the heading. +'target' instead of the heading. We use the term 'target' here similar to +the way'anchor' is used in HTML. .. note:: @@ -92,7 +95,7 @@ This creates a link to the :ref:`target ` using the word External References ******************* -External references or hyperlinks can be added easily with ReST. Only +External references or hyperlinks can be added easily with reST. Only hyperlinks with a separated target definition are allowed. Do not use explicit hyperlinks consisting entire URLs. For example, links @@ -121,4 +124,30 @@ Use this template to add a hyperlink with a separated definition: The state of `Oregon`_ offers a wide range of recreational activities. - .. _Oregon: http://traveloregon.com/ +The include directive +********************* + +Clear Linux documentation also uses the ``.. include::`` +directive to include a portion of another reST file. + +Use the ``.. include::`` directive to show a select portion of a file. + +.. code-block:: console + + .. include:: rest.rst + :start-after: incl-restructured-text-overview: + :end-before: incl-restructured-text-overview-end: + +In this example, note that you must: + +* Create a `target` that appears directly above a header (ease of inclusion) +* Ensure that the target is unique, as explained in :ref:`target ` +* Use a `:` at the end of the value of `start-after` and `end-before`. + +Use of the ``.. inclusion::`` for :ref:`rest` is shown below. + +.. include:: rest.rst + :start-after: incl-restructured-text-overview: + :end-before: incl-restructured-text-overview-end: + +.. _Oregon: http://traveloregon.com/ diff --git a/source/clear-linux/reference/collaboration/documentation/documentation.rst b/source/clear-linux/reference/collaboration/documentation/documentation.rst index b16ce41b..c9040c58 100644 --- a/source/clear-linux/reference/collaboration/documentation/documentation.rst +++ b/source/clear-linux/reference/collaboration/documentation/documentation.rst @@ -36,7 +36,7 @@ The |CL| technical content is written in simple American English and our This guide includes the following sections: .. toctree:: - :maxdepth: 2 + :maxdepth: 3 basic structures @@ -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/collaboration/documentation/rest.rst b/source/clear-linux/reference/collaboration/documentation/rest.rst index 3b1a81f6..43c71097 100644 --- a/source/clear-linux/reference/collaboration/documentation/rest.rst +++ b/source/clear-linux/reference/collaboration/documentation/rest.rst @@ -3,12 +3,19 @@ RestructuredText guide ###################### +.. incl-restructured-text-overview: + +Overview +******** + The |CLOSIA| uses Sphinx and RestructuredText as authoring tools for its documentation. This section contains the preferred methods for using the :abbr:`ReST (RestructuredText)` markup on your documents. Please refer to the `Sphinx documentation`_ for the complete list of available markup and use as much markup as possible. +.. _Sphinx documentation: http://www.sphinx-doc.org/en/stable/markup/index.html + Remember: **Changing incorrect markup is easier than adding markup from scratch.** @@ -27,6 +34,8 @@ templates, or the code-block directive, for multi-lined templates. Every use case is explained, examples provided and, lastly, templates supplied. +.. incl-restructured-text-overview-end: + .. toctree:: :maxdepth: 3 @@ -38,6 +47,3 @@ templates supplied. code contents - -.. _Sphinx documentation: - http://sphinx-doc.org/contents.html diff --git a/source/clear-linux/reference/compatible-hardware.rst b/source/clear-linux/reference/compatible-hardware.rst new file mode 100644 index 00000000..98bceeef --- /dev/null +++ b/source/clear-linux/reference/compatible-hardware.rst @@ -0,0 +1,113 @@ +.. _compatible-hardware: + +Compatible Hardware +################### + +This document describes hardware that has been tested and confirmed as +compatible with |CLOSIA|. This list is not comprehensive and will continue to +grow. + +.. list-table:: **Table 1. Clear Linux Compatible Hardware** + :widths: 20, 20 + :header-rows: 1 + + * - Processor SKU + - Platform + + * - Intel® Core™ i5-6260U + - + + * - Intel® Core™ i5-6560U + - Dell XPS\* 13 9350 + + * - Intel® Celeron® J3455 + - NUC6CAYS + + * - Intel® Core™ i5-4250U + - + + * - Intel® Core™ i7-5557U + - + + * - Intel® Core™ i9-7900X + - Gigabyte\* X299 + + * - Intel® Core™ i3-4130 + - Lenovo Thinkserver\* TS140 + + * - Intel® Core™ i7-7567U + - NUC7i7BNH + + * - Intel® Core™ i7-8809G + - NUC8i7HVK + + * - Intel® Core™ i5-7260U + - NUC7i5BNH + + * - Intel® Core™ i7-8650U + - NUC7i7DNKE + + * - Intel® Core™ i5-7300U + - NUC7i5DNHE + + * - Intel® Xeon® Gold 6138 + - + + * - Intel® Xeon® E5-2699A v4 + - Dell PowerEdge\* R630 + + * - Intel® Xeon® E5-2620 v3 + - + + * - Intel® Core™ i5-6600 + - Gigabyte\* Z170X-UD5 + + * - Intel® Core™ i5-4250U + - D54250WYK + + * - Intel® Xeon® E5-2699 v3 + - S2600WT2 + + * - Intel® Atom™ J3455 + - NUC6CAYB + + * - Intel® Xeon® Bronze 3104 + - 0W23H8 + + * - Intel® Atom™ C2750 + - SuperMicro\* A1SAi + + * - Intel® Atom™ E3825 + - CircuitCo MinnowBoard MAX\* + + * - Intel® Core™ i7-8700 + - Gigabyte\* H370 WIFI + + * - Intel® Core™ i7-3667U + - Lenovo ThinkPad\* X1 Carbon laptop + + * - Intel® Core™ i5-4210U + - Dell XPS\* 13 laptop + + * - Intel® Celeron® J3455 + - NUC6CAYB + + * - Intel® Core™ i7-4790 + - Gigabyte\* desktop + + * - Intel® Core™ i5-6260U + - NUC6I6SYH + + * - Intel® Core™ i7-5557U + - NUC5I7RYH + + * - Intel® Core™ i7-4700MQ + - Lenovo ThinkPad\* T540p + + * - Intel® Core™ i7-5557U + - NUC5I7RYB + + * - Intel® Core™ i5-6260U + - NUC6I5SYH + +\* Other names and brands may be claimed as the property of others. \ No newline at end of file diff --git a/source/clear-linux/reference/reference.rst b/source/clear-linux/reference/reference.rst index b7ec6e29..1ad206a7 100644 --- a/source/clear-linux/reference/reference.rst +++ b/source/clear-linux/reference/reference.rst @@ -9,9 +9,11 @@ features. .. toctree:: :maxdepth: 2 + compatible-hardware bundle-commands bundles/available-bundles 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..ea6699ed 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 +:: 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/multi-boot/multi-boot.rst b/source/clear-linux/tutorials/multi-boot/multi-boot.rst index 7c0e49d1..57e0af9e 100644 --- a/source/clear-linux/tutorials/multi-boot/multi-boot.rst +++ b/source/clear-linux/tutorials/multi-boot/multi-boot.rst @@ -53,7 +53,7 @@ RAM and a 360GB SSD. Table 1 lists the information specific to the installation of the tested operating systems. .. csv-table:: Table 1: OS specific installation information - :header: # , OS, Version, Partition Size [1], Swap Size [2], EFI Partition Size [3], Download Link + :header: # , OS, Version, Partition Size [#]_, Swap Size [#]_, EFI Partition Size [#]_, Download Link 1,Clear Linux,16140,50 GB,8 GB,1 GB,https://download.clearlinux.org/releases/16140/clear/ 2,Windows,Server 2016,50 GB,N/A,Shared with #1,https://www.microsoft.com/en-us/cloud-platform/windows-server diff --git a/source/clear-linux/tutorials/telemetry-backend/telemetry-backend.rst b/source/clear-linux/tutorials/telemetry-backend/telemetry-backend.rst index f2f10160..4b026f4e 100644 --- a/source/clear-linux/tutorials/telemetry-backend/telemetry-backend.rst +++ b/source/clear-linux/tutorials/telemetry-backend/telemetry-backend.rst @@ -100,35 +100,35 @@ Run the deploy.sh script to install the backend server The :command:`deploy.sh` is a bash shell script that allows you to perform the following actions: -* :option:`deploy` - install a complete instance of the telemetrics backend +* *deploy* - install a complete instance of the telemetrics backend server and all required components. This is the default action if no - :option:`-a` argument is given on the command line. -* :option:`install` - installs and enables all required components for the + *-a* argument is given on the command line. +* *install* - installs and enables all required components for the telemetrics backend server. -* :option:`migrate` - migrate database to new schema. -* :option:`resetdb` - reset the database. -* :option:`restart` - restart the nginx and uWSGI services. -* :option:`uninstall` - uninstall all packages. +* *migrate* - migrate database to new schema. +* *resetdb* - reset the database. +* *restart* - restart the nginx and uWSGI services. +* *uninstall* - uninstall all packages. .. note:: - The :option:`uninstall` option does not perform any actions if the + The *uninstall* option does not perform any actions if the distro is set to |CL| and will only uninstall packages if the distro is Ubuntu Next, we install the telemetrics backend server with the following options: -* :option:`-a install` to perform an install -* :option:`-d clr` to install to a |CL| distro -* :option:`-H localhost` to set the domain to localhost +* *-a install* to perform an install +* *-d clr* to install to a |CL| distro +* *-H localhost* to set the domain to localhost We do not need to set the following options since the values are set to the correct values we want by default: -* :option:`-r https://github.com/clearlinux/telemetrics-backend` sets the +* *-r https://github.com/clearlinux/telemetrics-backend* sets the repo location for :command:`git` to clone from. -* :option:`-s master` to set the location, or branch. -* :option:`-t git` to set the source type to git. +* *-s master* to set the location, or branch. +* *-t git* to set the source type to git. .. caution:: The :file:`deploy.sh` shell script has minimal error checking and makes diff --git a/source/clear-linux/tutorials/tutorials.rst b/source/clear-linux/tutorials/tutorials.rst index 9bc120ad..c312c8ad 100644 --- a/source/clear-linux/tutorials/tutorials.rst +++ b/source/clear-linux/tutorials/tutorials.rst @@ -3,6 +3,13 @@ Tutorials ######### +Our Tutorials: + +* Demonstrate how to use |CL| features for cloud, client, distributed + processing, and virtual environments +* Involve specific application of |CL| that often use third-party tools +* Extend the development possibilities of |CL| with specific use cases + This section provides detailed instructions to guide you through completing specific |CLOSIA| use cases. 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"]