Doc: Restructure clean up.
This commit fixes all warnings about cross-references and file names. It addresses all mark-up issues. Only the warnings regarding Doxygen objects and files that are intentionally not added to a toctree are left unhandled. Change-Id: I5d840522ea0bade4f183e447745244aecf893c94 Signed-off-by: Rodrigo Caballero <rodrigo.caballero.abraham@intel.com>
This commit is contained in:
Rodrigo Caballero
Anas Nashif
parent
a98d0dd5e3
commit
5753b6e4dc
24 changed files with 123 additions and 133 deletions
|
|
@ -8,7 +8,7 @@ applies for developers that are new to open source as well as for
|
|||
experienced open source developers.
|
||||
|
||||
Change Requirements
|
||||
******************
|
||||
*******************
|
||||
|
||||
Here you can find the required format and content for changes. For more
|
||||
information on how to submit a change using Gerrit please refer to
|
||||
|
|
@ -28,7 +28,7 @@ example, which tests you ran.
|
|||
Commits must build cleanly when applied in top of each other, thus
|
||||
avoiding breaking bisectability. Commits must pass the
|
||||
:file:`scripts/checkpatch.pl` requirements. For more details see the
|
||||
:ref:`style` section. Each commit must address a single identifiable
|
||||
:ref:`coding_style` section. Each commit must address a single identifiable
|
||||
issue and must be logically self contained.
|
||||
|
||||
For example: One commit fixes whitespace issues, another renames a
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ to the @def on line 2.
|
|||
|
||||
Incorrect:
|
||||
|
||||
.. literalinclude:: ../../samples/microkernel/apps/philosophers/src/phil.h
|
||||
.. literalinclude:: ../../../../samples/microkernel/apps/philosophers/src/phil.h
|
||||
:language: c
|
||||
:lines: 42-47
|
||||
:emphasize-lines: 2, 5
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ Example 1
|
|||
|
||||
Take the very simple function :c:func:`taskA()`:
|
||||
|
||||
.. literalinclude:: ../../samples/microkernel/apps/hello_world/src/hello.c
|
||||
.. literalinclude:: ../../../../samples/microkernel/apps/hello_world/src/hello.c
|
||||
:language: c
|
||||
:lines: 77-85
|
||||
:emphasize-lines: 3, 6
|
||||
|
|
@ -99,7 +99,7 @@ Example 2
|
|||
=========
|
||||
Take the more complex function hello_loop():
|
||||
|
||||
.. literalinclude:: ../../samples/microkernel/apps/hello_world/src/hello.c
|
||||
.. literalinclude:: ../../../../samples/microkernel/apps/hello_world/src/hello.c
|
||||
:language: c
|
||||
:lines: 56-76
|
||||
:emphasize-lines: 1, 3-5, 7, 8, 13, 16
|
||||
|
|
@ -122,7 +122,7 @@ Lines 13 and 16 contain two comments that won't be included by Doxygen
|
|||
in the documentation. Use the brief description or the detailed
|
||||
description inside the comment block to include that information.
|
||||
Remember that variables have to be documented separately. See
|
||||
:ref:`Variable Documentation` for more details.
|
||||
:ref:`variable_documentation` for more details.
|
||||
|
||||
.. literalinclude:: hello_commented.c
|
||||
:language: c
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ separates each group of variable and comment.
|
|||
|
||||
Incorrect:
|
||||
|
||||
.. literalinclude:: ../../samples/include/irq_test_common.h
|
||||
.. literalinclude:: ../../../../samples/include/irq_test_common.h
|
||||
:language: c
|
||||
:lines: 112-115
|
||||
:emphasize-lines: 1
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ appropriately.
|
|||
|
||||
Incorrect:
|
||||
|
||||
.. literalinclude:: ../../samples/include/irq_test_common.h
|
||||
.. literalinclude:: ../../../../samples/include/irq_test_common.h
|
||||
:language: c
|
||||
:lines: 67-72
|
||||
:emphasize-lines: 3, 4
|
||||
|
|
|
|||
|
|
@ -67,5 +67,5 @@ comment is only a sentence fragment.
|
|||
Notice that the variable comments also apply for more complex types like
|
||||
structs. The comments on lines 4 and 7 apply only to the specific
|
||||
variable and not to the whole struct. Complex types must be documented
|
||||
wherever they are defined. See :ref:`Structure Documentation` and
|
||||
:ref:`Type Definition Documentation` for further details.
|
||||
wherever they are defined. See :ref:`structure_documentation` and
|
||||
:ref:`type_definition_documentation` for further details.
|
||||
|
|
@ -5,7 +5,7 @@ Working with Gerrit
|
|||
|
||||
|
||||
Follow these instructions to collaborate on the |project| using
|
||||
the infrastructure within Intel’s Open Source site, 01.org_. First, let
|
||||
the infrastructure within Intel’s Open Source site, ``01.org``. First, let
|
||||
us answer a couple of common questions regarding the use of Gerrit
|
||||
within the |project|.
|
||||
|
||||
|
|
@ -137,11 +137,13 @@ Reviewing Using Gerrit
|
|||
will auto-complete based on the list of people registered and with
|
||||
access to the system. They will be notified by email that you are
|
||||
requesting their input.
|
||||
|
||||
* Abandon: This button is only available to the submitter, allowing
|
||||
the committer to abandon this change and get no more work done on
|
||||
it.
|
||||
|
||||
* Change-ID: This is an ID generated by Gerrit (or system). This is
|
||||
useful when the review process determines that your commit(s) have to
|
||||
useful when the review process determines that your commit(s) have to
|
||||
be redone. You can upload a new version and if the same Change-ID
|
||||
header (and value) are present, Gerrit will remember it and present
|
||||
it as another version of the same change.
|
||||
|
|
@ -152,7 +154,6 @@ Reviewing Using Gerrit
|
|||
merge, -1 if they disagree. Gerrit users with a Maintainer role can
|
||||
agree to the merge or refuse it by voting +2 or -2 respectively.
|
||||
|
||||
|
||||
Notifications are sent to the email address in your commit message's
|
||||
Signed-off-by line. Visit
|
||||
`your gerrit page <https://oic-review.01.org/gerrit/#/dashboard/self>`_,
|
||||
|
|
|
|||
|
|
@ -41,10 +41,10 @@ refer to these groups as writers and authors.
|
|||
Methodology
|
||||
***********
|
||||
|
||||
The :ref:`style` contains exceptions to the other style guides. It also
|
||||
The :ref:`documentation` contains exceptions to the other style guides. It also
|
||||
contains additional material not found in those sources.
|
||||
|
||||
To research a style question, look in the :ref:`style` first. If the
|
||||
To research a style question, look in the :ref:`documentation` first. If the
|
||||
question is not answered there, send your question to the
|
||||
`mailing list`_. For hyphenation, spelling, or terminology usage
|
||||
questions look in the Merriam-Webster's Collegiate Dictionary.
|
||||
|
|
@ -74,7 +74,7 @@ do we always agree with these sources. In areas where there is
|
|||
disagreement, the decisions made may be explained within the respective
|
||||
section.
|
||||
|
||||
The :ref:`style` takes precedence over all other style guides in all
|
||||
The :ref:`documentation` takes precedence over all other style guides in all
|
||||
cases. In cases where the guide does not address the issue at hand the
|
||||
issue must be reported to the `mailing list`_.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,16 +9,16 @@ written directly in the documentation or included from a source file.
|
|||
Use these guidelines to insert code blocks to your documentation:
|
||||
|
||||
* Include code examples from a source file . Only write the code
|
||||
example directly into the documentation if the example is less than 10
|
||||
lines long or not part of the code base of |codename|.
|
||||
example directly into the documentation if the example is less than 10
|
||||
lines long or not part of the code base of |codename|.
|
||||
|
||||
* Use the ``:lineos:`` option of the directives to add line numbers to
|
||||
your example if it is larger than 12 lines.
|
||||
your example if it is larger than 12 lines.
|
||||
|
||||
* Specify the programing language of your example. Not only will it
|
||||
add syntax highlighting but it also allows the reader to identify code
|
||||
efficiently. Use bash for console commands, asm for assembly code and
|
||||
c for C code.
|
||||
add syntax highlighting but it also allows the reader to identify code
|
||||
efficiently. Use bash for console commands, asm for assembly code and
|
||||
c for C code.
|
||||
|
||||
* Treat all console commands that a user must use as code examples.
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ renumbered and the 7th, 11th and 13th lines are highlighted.
|
|||
|
||||
.. code-block:: rst
|
||||
|
||||
.. literalinclude:: ../doxygen/hello_commented.c
|
||||
.. literalinclude:: ../code/doxygen/hello_commented.c
|
||||
:language: c
|
||||
:lines: 97-110
|
||||
:emphasize-lines: 7, 11, 13
|
||||
|
|
@ -39,7 +39,7 @@ renumbered and the 7th, 11th and 13th lines are highlighted.
|
|||
|
||||
Renders as:
|
||||
|
||||
.. literalinclude:: ../doxygen/hello_commented.c
|
||||
.. literalinclude:: ../code/doxygen/hello_commented.c
|
||||
:language: c
|
||||
:lines: 97-110
|
||||
:emphasize-lines: 7, 11, 13
|
||||
|
|
|
|||
|
|
@ -47,14 +47,14 @@ Do not use labels like these:
|
|||
|
||||
.. _building:
|
||||
|
||||
This is an internal reference to the beginning of :ref:`rest_guideline`.
|
||||
This is an internal reference to the beginning of :ref:`restructured`.
|
||||
|
||||
Observe that the ``:ref:`` markup is replaced with the title's text.
|
||||
Similarly, it will be replaced with the figure's caption. If a different
|
||||
text is needed the ``:ref:`` markup can still be used.
|
||||
|
||||
This is an internal reference to the beginning of
|
||||
:ref:`this module <rest_guideline>`.
|
||||
:ref:`this module <restructured>`.
|
||||
|
||||
Use the following templates to insert internal cross references properly.
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ reference to a documented code element.
|
|||
|
||||
.. caution::
|
||||
References to in-code documentation only work if the element has been
|
||||
documented in the code following the :ref:`code_documentation_guidelines`.
|
||||
documented in the code following the :ref:`contributing_code`.
|
||||
|
||||
External References
|
||||
===================
|
||||
|
|
@ -135,12 +135,12 @@ While both methods are accpeted, hyperlinks with a separated target
|
|||
definition are preferred. Follow these guidelines when inserting hyperlinks:
|
||||
|
||||
* The labels for hyperlinks must be grammatically correct and unique within
|
||||
the module.
|
||||
the module.
|
||||
|
||||
* Do not create labels for hyperlinks using: link, here, this, there, etc.
|
||||
|
||||
* Add all target definitions at the end of the section containing the
|
||||
hyperlinks.
|
||||
hyperlinks.
|
||||
|
||||
Use this template to add a hyperlink with a separated definition:
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Scope
|
|||
|
||||
This guide includes the following:
|
||||
|
||||
:ref:`basic`
|
||||
:ref:`basic_writing`
|
||||
|
||||
Covers the basic issues of writing styles, including general writing
|
||||
guidelines and specific guidelines for step-by-step procedures.
|
||||
|
|
@ -25,7 +25,7 @@ guidelines and specific guidelines for step-by-step procedures.
|
|||
:ref:`detailed`
|
||||
|
||||
Offers specific examples of all guidelines included in the
|
||||
:ref:`basic`. Additionally, it contains the guidelines for
|
||||
:ref:`basic_writing`. Additionally, it contains the guidelines for
|
||||
module-based writing.
|
||||
|
||||
:ref:`language`
|
||||
|
|
@ -38,7 +38,7 @@ capitalization, and various rules about writing technical documents.
|
|||
Specifically addresses writing standards and syntax with regard to
|
||||
Restructuredtext.
|
||||
|
||||
:ref:`about`
|
||||
:ref:`about_docs_style`
|
||||
|
||||
Contains all the information regarding the guidelines above including the references used, the
|
||||
intended audience and the methodology employed.
|
||||
|
|
|
|||
|
|
@ -14,36 +14,36 @@ text.
|
|||
Follow these guidelines when creating graphics for the |project|:
|
||||
|
||||
* Captions. Include a caption to explain or describe what the graphic
|
||||
illustrates or to use as a navigational tool when referring to the
|
||||
graphic from another location. All graphics should have a caption.
|
||||
illustrates or to use as a navigational tool when referring to the
|
||||
graphic from another location. All graphics should have a caption.
|
||||
|
||||
* Use cross references. Refer to your graphics in the main text flow.
|
||||
Create a label using the filename of the image. Use``:ref:`` to place
|
||||
the cross reference, see :ref:`internal_cross` for more details. Place
|
||||
the graphic immediately after its reference in the text flow or as
|
||||
close as possible.
|
||||
Create a label using the filename of the image. Use``:ref:`` to place
|
||||
the cross reference, see :ref:`internal_cross` for more details. Place
|
||||
the graphic immediately after its reference in the text flow or as
|
||||
close as possible.
|
||||
|
||||
* Keep graphics simple. They should only contain the information the
|
||||
reader needs.
|
||||
reader needs.
|
||||
|
||||
* Use graphics judiciously. Don't use superfluous graphics and don't
|
||||
use graphics as mere decorations; they must have purpose. You don't
|
||||
need to show a screenshot of every single step or window in a software
|
||||
installation procedure, for example.
|
||||
use graphics as mere decorations; they must have purpose. You don't
|
||||
need to show a screenshot of every single step or window in a software
|
||||
installation procedure, for example.
|
||||
|
||||
* Avoid volatility. Don't incorporate information into a graphic that
|
||||
might change with each release, for example, product versions or
|
||||
codename abbreviations.
|
||||
might change with each release, for example, product versions or
|
||||
codename abbreviations.
|
||||
|
||||
* Use only approved formats. Use either PNG or JPEG bitmap files for
|
||||
screenshots and SVG files for vector graphics. Graphics that do not
|
||||
constitute photographs or screenshots must be provided as vector
|
||||
graphics to ensure that they can be changed.
|
||||
screenshots and SVG files for vector graphics. Graphics that do not
|
||||
constitute photographs or screenshots must be provided as vector
|
||||
graphics to ensure that they can be changed.
|
||||
|
||||
* Provide the source files. Save the source artwork files with the
|
||||
documentation in a separate :file:`figures` folder. The filename must
|
||||
follow the naming conventions of the project, for example: :file:`
|
||||
fibers.svg` or :file:`nanokernel_fiber-1.png`.
|
||||
documentation in a separate :file:`figures` folder. The filename must
|
||||
follow the naming conventions of the project, for example: :file:`
|
||||
fibers.svg` or :file:`nanokernel_fiber-1.png`.
|
||||
|
||||
Examples
|
||||
========
|
||||
|
|
|
|||
|
|
@ -12,26 +12,26 @@ following markup for every instance you encounter unless otherwise
|
|||
specified.
|
||||
|
||||
* Use the 'abbreviation' markup to define an acronym or an initialism.
|
||||
The abbreviation only needs to be added once per module. Ensure that
|
||||
any acronym or initialism used in a module has been defined at least
|
||||
once, otherwise the submission will not be accepted.
|
||||
The abbreviation only needs to be added once per module. Ensure that
|
||||
any acronym or initialism used in a module has been defined at least
|
||||
once, otherwise the submission will not be accepted.
|
||||
|
||||
:abbr:`API (Application Program Interface)`
|
||||
|
||||
``:abbr:`TIA (This Is an Abbreviation)```
|
||||
|
||||
* Use the 'command' markup only when the name of a specific command is
|
||||
used as part of a paragraph for emphasis. Use the ``.. code-block::``
|
||||
directive to supply full actionable commands as part as a series of
|
||||
steps.
|
||||
used as part of a paragraph for emphasis. Use the ``.. code-block::``
|
||||
directive to supply full actionable commands as part as a series of
|
||||
steps.
|
||||
|
||||
:command:`make`
|
||||
|
||||
``:command:`command```
|
||||
|
||||
* Use the 'option' markup to emphasize the name of a command option
|
||||
with or without its value. This markup is usually employed in
|
||||
combination with the 'command' markup.
|
||||
with or without its value. This markup is usually employed in
|
||||
combination with the 'command' markup.
|
||||
|
||||
:option:`-f`
|
||||
:option:`--all`
|
||||
|
|
@ -43,18 +43,18 @@ combination with the 'command' markup.
|
|||
``:option:`Option```
|
||||
|
||||
* Use the 'file' markup to emphasize a filename or directory. Do not
|
||||
use the markup inside a code-block but use it inside all notices that
|
||||
contain files or directories.
|
||||
use the markup inside a code-block but use it inside all notices that
|
||||
contain files or directories.
|
||||
|
||||
:file:`collaboration.rst` :file:`doc/collaboration/figures`
|
||||
|
||||
``:file:`filename.ext` :file:`path/or/directory```
|
||||
|
||||
* Use the 'guilabel' markup to emphasize the elements in 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.
|
||||
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.
|
||||
|
||||
In the :guilabel:`Tools` menu.
|
||||
Press the :guilabel:`OK` button.
|
||||
|
|
@ -64,10 +64,10 @@ noun.
|
|||
``:guilabel:`UI-Label```
|
||||
|
||||
* Use the 'menuselection' markup 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.
|
||||
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.
|
||||
|
||||
:menuselection:`File --> Save As --> PDF`
|
||||
Go to :guilabel:`File` and select :menuselection:`Import --> Data
|
||||
|
|
@ -77,9 +77,9 @@ are required, it can be combined with a 'guilabel' or with another
|
|||
|
||||
``:menuselection:`1stMenu --> 2ndMenu --> Selection```
|
||||
|
||||
* Use the 'makevar' markup to emphasize the name of a Makefile variable
|
||||
. The markup can include only the name of the variable or the variable
|
||||
plus its value.
|
||||
* Use the 'makevar' markup to emphasize the name of a Makefile variable.
|
||||
The markup can include only the name of the variable or the variable
|
||||
plus its value.
|
||||
|
||||
:makevar:`PLATFORM_CONFIG`
|
||||
:makevar:`PLATFORM_CONFIG=basic_atom`
|
||||
|
|
@ -87,8 +87,8 @@ plus its value.
|
|||
``:makevar:`VARIABLE```
|
||||
|
||||
* Use the 'envvar' markup to emphasize the name of environment
|
||||
variables. Just as with 'makevar', the markup can include only for the
|
||||
name of the variable or the variable plus its value.
|
||||
variables. Just as with 'makevar', the markup can include only for the
|
||||
name of the variable or the variable plus its value.
|
||||
|
||||
:envvar:`ZEPHYR_BASE`
|
||||
:envvar:`QEMU_BIN_PATH=/usr/local/bin`
|
||||
|
|
|
|||
|
|
@ -70,16 +70,14 @@ It is acceptable to refer to these items generically by using
|
|||
lowercase letters if it is clear that your reference is generic and
|
||||
not a specific name of a window or field on a menu, for example:
|
||||
|
||||
* Click :guilabel:`Edit` to display the
|
||||
:guilabel:`Widget Configuration ` window.
|
||||
Click :guilabel:`Edit` to display the :guilabel:`Widget Configuration` window.
|
||||
|
||||
* The widget configuration window has several advanced widget
|
||||
configuration options.
|
||||
The widget configuration window has several advanced widget configuration options.
|
||||
|
||||
This second bullet could have capitalized the term "Widget
|
||||
The second sentence could have capitalized the term "Widget
|
||||
Configuration window"; but there are times when you might want to
|
||||
refer to something with a generic descriptor and not its name. Observe
|
||||
the use of the |ReST| markup ``:guilabel:`` on the first bullet.
|
||||
the use of the ReST markup ``:guilabel:`` on the first sentence.
|
||||
|
||||
A few other menu capitalization rules to keep in mind:
|
||||
|
||||
|
|
@ -297,8 +295,8 @@ WidgetPro's an awesome product.
|
|||
|
||||
Hyphenation
|
||||
***********
|
||||
The hyphen is often used to join words together to form a compound noun
|
||||
. Compoundnouns often go through this progressions:
|
||||
The hyphen is often used to join words together to form a compound noun.
|
||||
Compound nouns often go through this progressions:
|
||||
|
||||
* open compound: health care
|
||||
* hyphenated compound: health-care
|
||||
|
|
@ -357,7 +355,7 @@ In general, do not hyphenate suffixes. Here are some examples.
|
|||
The suffix -wide is usually not hyphenated:
|
||||
|
||||
* Nationwide, worldwide, systemwide, campuswide, statewide,
|
||||
companywide, etc.
|
||||
companywide, etc.
|
||||
|
||||
The suffix -wise is usually not hyphenated:
|
||||
|
||||
|
|
@ -423,7 +421,7 @@ Idaho; and Eugene, Oregon.
|
|||
Colons ":"
|
||||
==========
|
||||
|
||||
If the text following a colon is a sentence, capitalize the
|
||||
If the text following a colon is a sentence, capitalize the
|
||||
first word after the colon. If the subsequent text is not a sentence,
|
||||
do not capitalize the first term unless it is a title. For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ modularization is still a work in progress and new content must be
|
|||
structured following this guidelines.
|
||||
|
||||
.. note::
|
||||
The guidelines presented in :ref:`generalWriting` still apply to
|
||||
The guidelines presented in :ref:`basic_writing` still apply to
|
||||
modular writing, except where specifically noted to the contrary.
|
||||
|
||||
Module Types
|
||||
|
|
@ -153,8 +153,7 @@ modules, including modules for page-level help and command-line options:
|
|||
with a third-person present-tense verb, as in Specifies...,
|
||||
Defines..., Creates....
|
||||
|
||||
* Use "See :ref:`cross-references`" for cross-references to supporting
|
||||
tasks and concepts.
|
||||
* Use "See :ref:`cross`" for cross-references to supporting tasks and concepts.
|
||||
|
||||
Module Structure
|
||||
****************
|
||||
|
|
|
|||
|
|
@ -27,8 +27,8 @@ templates are supplied.
|
|||
tables
|
||||
cross
|
||||
images
|
||||
code
|
||||
code_blocks
|
||||
|
||||
|
||||
.. _Sphinx documentation:
|
||||
http://sphinx-doc.org/contents.html
|
||||
http://sphinx-doc.org/contents.html
|
||||
|
|
|
|||
|
|
@ -183,10 +183,10 @@ Examples:
|
|||
**We released version 2.0 in June.**
|
||||
|
||||
.. note::
|
||||
Sometimes it is okay to use passive voice. For example, you may
|
||||
use passive voice to avoid gender-specific pronouns, to avoid
|
||||
blaming someone, or to address situations where the subject, who
|
||||
did the action, is unknown or irrelevant.
|
||||
Sometimes it is okay to use passive voice. For example, you may
|
||||
use passive voice to avoid gender-specific pronouns, to avoid
|
||||
blaming someone, or to address situations where the subject, who
|
||||
did the action, is unknown or irrelevant.
|
||||
|
||||
Noun phrases
|
||||
************
|
||||
|
|
@ -293,8 +293,7 @@ If a user needs to update his account...
|
|||
|
||||
In traditional English usage, it is acceptable to use the masculine
|
||||
pronoun set (he) when the gender is neutral or indeterminate.
|
||||
This is often the rule in romance languages
|
||||
and other languages.
|
||||
This is often the rule in romance languages and other languages.
|
||||
|
||||
**Preferred**
|
||||
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ before you embark on creating a table. Follow these general guidelines:
|
|||
* Keep the 72-78 characters line length in mind.
|
||||
|
||||
* Indent the contents correctly. This allows the content to be read even if
|
||||
it is not rendered.
|
||||
it is not rendered.
|
||||
|
||||
* Only create a table if the body of the table is larger than 6, that means
|
||||
either 2x3 or 3x2.
|
||||
either 2x3 or 3x2.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,8 +4,7 @@
|
|||
.. rubric:: Disclaimer
|
||||
|
||||
.. important::
|
||||
|
||||
This documentation is a work in progress and is being provided for
|
||||
informative purposes only. Because it is a work in progress, there are
|
||||
parts that are either missing or will be revised as code development
|
||||
continues.
|
||||
This documentation is a work in progress and is being provided for
|
||||
informative purposes only. Because it is a work in progress, there are
|
||||
parts that are either missing or will be revised as code development
|
||||
continues.
|
||||
|
|
|
|||
|
|
@ -6,28 +6,21 @@
|
|||
|
||||
.. include:: disclaimers.rst
|
||||
|
||||
The Zephyr Kernel Documentation
|
||||
###############################
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
quick_start/quick_start.rst
|
||||
kernel/kernel.rst
|
||||
application/application.rst
|
||||
platform/platform.rst
|
||||
quick_start/quick_start
|
||||
kernel/kernel
|
||||
application/application
|
||||
platform/platform
|
||||
collaboration/collaboration
|
||||
reference/reference
|
||||
|
||||
Reference Guides
|
||||
################
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
reference/api.rst
|
||||
reference/configuration.rst
|
||||
reference/kbuild.rst
|
||||
|
||||
|
||||
Indices and tables
|
||||
##################
|
||||
Indexes and Tables
|
||||
******************
|
||||
|
||||
* :ref:`genindex`
|
||||
|
||||
|
|
|
|||
|
|
@ -16,3 +16,4 @@ applications and nanokernel applications.
|
|||
nanokernel_synchronization
|
||||
nanokernel_data
|
||||
nanokernel_interrupts
|
||||
nanokernel_example
|
||||
|
|
|
|||
|
|
@ -26,10 +26,10 @@ development platform and for kernel developers looking to modify or
|
|||
expand the kernel functionality.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth:2
|
||||
:maxdepth: 2
|
||||
|
||||
kbuild_kconfig
|
||||
kbuild_makefiles
|
||||
kbuild_projects
|
||||
kbuild_project
|
||||
kbuild_targets
|
||||
kbuild_toolchains
|
||||
13
doc/reference/reference.rst
Normal file
13
doc/reference/reference.rst
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
.. _reference:
|
||||
|
||||
Development Reference Guides
|
||||
############################
|
||||
|
||||
This section contains all reference guides that might be needed during development.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
api
|
||||
configuration
|
||||
kbuild
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
.. _zephyr_project:
|
||||
|
||||
The Zephyr Project
|
||||
##################
|
||||
|
||||
This section contains the information about the open source project.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
collaboration/collaboration.rst
|
||||
doxygen/doxygen.rst
|
||||
documentation/documentation.rst
|
||||
Loading…
Add table
Add a link
Reference in a new issue