doc: initial doc commit

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
David B. Kinder 2018-03-05 22:54:44 -08:00 committed by lijinxia
parent 981dd9ac88
commit d7938f8ca8
22 changed files with 4914 additions and 1 deletions

4
doc/.gitignore vendored Normal file
View File

@ -0,0 +1,4 @@
doxygen
_build
devicemodel
hypervisor

28
doc/Makefile Normal file
View File

@ -0,0 +1,28 @@
# Minimal makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = sphinx-build
SPHINXPROJ = "Project ACRN"
SOURCEDIR = .
BUILDDIR = _build
# Put it first so that "make" without argument is like "make help".
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
.PHONY: help Makefile
doxy:
$(Q)(cat doxyfile) | doxygen - 2>&1
clean:
$(Q)(rm -fr $(BUILDDIR) doxygen)
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile doxy
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

View File

@ -1 +0,0 @@
# acrn-documentation

View File

@ -0,0 +1,9 @@
.. _devicemodel_apis:
Device Model APIs
#################
This section contains APIs for the SOS Device Model services.
.. doxygengroup:: acrn_virtio
:project: Project ACRN

View File

@ -0,0 +1,9 @@
.. _hypercall_apis:
Hypercall APIs
##############
This section contains APIs for the hypercall services.
.. doxygengroup:: acrn_hypercall
:project: Project ACRN

11
doc/api/index.rst Normal file
View File

@ -0,0 +1,11 @@
.. _acrn_apis:
Project ACRN APIs
#################
.. toctree::
:maxdepth: 1
hypercall_api.rst
devicemodel_api.rst

189
doc/conf.py Normal file
View File

@ -0,0 +1,189 @@
# -*- coding: utf-8 -*-
#
# Project ACRN documentation build configuration file, created by
# sphinx-quickstart on Wed Jan 10 20:51:29 2018.
#
# This file is execfile()d with the current directory set to its
# containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#
import os
import sys
sys.path.insert(0, os.path.abspath('.'))
# -- General configuration ------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
#
# needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = ['breathe']
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix(es) of source filenames.
# You can specify multiple suffix as a list of string:
#
# source_suffix = ['.rst', '.md']
source_suffix = '.rst'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'Project ACRN'
copyright = u'2018, Project ACRN'
author = u'Project ARCN developers'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
version = u'1.0.0'
# The full version, including alpha/doc/beta/doc/rc tags.
release = u'1.0.0'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#
# This is also used if you do content translation via gettext catalogs.
# Usually you set "language" from the command line for these cases.
language = None
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
# This patterns also effect to html_static_path and html_extra_path
exclude_patterns = ['_build' ]
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# If true, `todo` and `todoList` produce output, else they produce nothing.
todo_include_todos = False
# -- Options for HTML output ----------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
#
try:
import sphinx_rtd_theme
except ImportError:
html_theme = 'alabaster'
# This is required for the alabaster theme
# refs: http://alabaster.readthedocs.io/en/latest/installation.html#sidebars
html_sidebars = {
'**': [
'relations.html', # needs 'show_related': True theme option to display
'searchbox.html',
]
}
else:
html_theme = "sphinx_rtd_theme"
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#
# html_theme_options = {}
html_logo = 'images/ACRNlogo.png'
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['static']
def setup(app):
app.add_stylesheet("acrn-custom.css")
# Custom sidebar templates, must be a dictionary that maps document names
# to template names.
#
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
html_show_sphinx = False
# If true, links to the reST sources are added to the pages.
html_show_sourcelink = False
# -- Options for HTMLHelp output ------------------------------------------
# Output file base name for HTML help builder.
htmlhelp_basename = 'ACRN Project Help'
# -- Options for LaTeX output ---------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#
# 'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#
# 'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#
# 'preamble': '',
# Latex figure (float) alignment
#
# 'figure_align': 'htbp',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'acrn.tex', u'Project ACRN Documentation',
u'Project ACRN', 'manual'),
]
# -- Options for manual page output ---------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
(master_doc, 'acrn', u'Project ACRN Documentation',
[author], 1)
]
# -- Options for Texinfo output -------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
(master_doc, 'Project ACRN', u'Project ACRN Documentation',
author, 'Project ACRN',
'IoT-Optimized Hypervisor for Intel Architecture',
'Miscellaneous'),
]
breathe_projects = {
"Project ACRN" : "doxygen/xml",
}
breathe_default_project = "Project ACRN"

354
doc/contribute.rst Normal file
View File

@ -0,0 +1,354 @@
.. _contribute:
Contribution Guidelines
#######################
As an open-source project, we welcome and encourage the community to
submit patches directly to Project ACRN. In our collaborative open
source environment, standards and methods for submitting changes help
reduce the chaos that can result from an active development community.
This document explains how to participate in project conversations, log
bugs and enhancement requests, and submit patches to the project so your
patch will be accepted quickly in the codebase.
Licensing
*********
Licensing is very important to open source projects. It helps ensure the
software continues to be available under the terms that the author
desired.
Project ACRN uses a BSD license, as found in the license_header in
the project's GitHub repo.
A license tells you what rights you have as a developer, as provided by
the copyright holder. It is important that the contributor fully
understands the licensing rights and agrees to them. Sometimes the
copyright holder isn't the contributor, such as when the contributor is
doing work on behalf of a company.
.. _DCO:
Developer Certification of Origin (DCO)
***************************************
To make a good faith effort to ensure licensing criteria are met,
Project ACRN requires the Developer Certificate of Origin (DCO) process
to be followed.
The DCO is an attestation attached to every contribution made by every
developer. In the commit message of the contribution, (described more
fully later in this document), the developer simply adds a
``Signed-off-by`` statement and thereby agrees to the DCO.
When a developer submits a patch, it is a commitment that the
contributor has the right to submit the patch per the license. The DCO
agreement is shown below and at http://developercertificate.org/.
.. code-block:: none
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the
best of my knowledge, is covered under an appropriate open
source license and I have the right under that license to
submit that work with modifications, whether created in whole
or in part by me, under the same open source license (unless
I am permitted to submit under a different license), as
Indicated in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including
all personal information I submit with it, including my
sign-off) is maintained indefinitely and may be redistributed
consistent with this project or the open source license(s)
involved.
DCO Sign-Off Methods
====================
The DCO requires a sign-off message in the following format appear on each
commit in the pull request::
Signed-off-by: acrnus acrn <acrnus@projectacrn.org>
The DCO text can either be manually added to your commit body, or you can add
either ``-s`` or ``--signoff`` to your usual Git commit commands. If you forget
to add the sign-off you can also amend a previous commit with the sign-off by
running ``git commit --amend -s``. If you've pushed your changes to GitHub
already you'll need to force push your branch after this with ``git push -f``.
Prerequisites
*************
.. _Project ACRN website: https://projectacrn.org
As a contributor, you'll want to be familiar with Project ACRN, how to
configure, install, and use it as explained in the `Project ACRN website`_
and how to set up your development environment as introduced in the
Project ACRN `Getting Started Guide`_.
.. _Getting Started Guide:
https://acrnproject.github.com/acrn-documentation/getting_started.html
You should be familiar with common developer tools such as Git and CMake, and
platforms such as GitHub.
If you haven't already done so, you'll need to create a (free) GitHub account
on http://github.com and have Git tools available on your development system.
Repository layout
*****************
To clone the main Project ACRN repository use::
git clone https://github.com/projectacrn/acrn-hypervisor
The Project ACRN directory structure is described in `Source Tree Structure`_
documentation. In addition to the Project ACRN hypervisor itself, you'll also find the
sources for technical documentation, sample code and supported board
configurations. All of these are available for developers to contribute to and enhance.
.. _Source Tree Structure:
https://projectacrn.github.io/acrn-documentation/
Pull Requests and Issues
************************
.. _ACRN-dev mailing list:
https://lists.projectacrn.org/g/acrn-dev
Before starting on a patch, first check in our issues in the `ACRN-dev
mailing list`_ system to see what's been reported on the issue you'd
like to address. Have a conversation on the `ACRN-dev mailing list`_ to
see what others think of your issue (and proposed solution). You may
find others that have encountered the issue you're finding, or that have
similar ideas for changes or additions. Send a message to the `ACRN-dev
mailing list`_ to introduce and discuss your idea with the development
community.
It's always a good practice to search for existing or related issues
before submitting your own. When you submit an issue (bug or feature
request), the triage team will review and comment on the submission,
typically within a few business days.
.. _Contribution Tools:
Contribution Tools and Git Setup
********************************
Signed-off-by
=============
The name in the commit message ``Signed-off-by:`` line and your email must
match the change authorship information. Make sure your :file:`.gitconfig`
is set up correctly:
.. code-block:: console
git config --global user.name "David Developer"
git config --global user.email "david.developer@company.com"
Coding Style
************
Use these coding guidelines to ensure that your development complies with the
project's style and naming conventions.
.. _Linux kernel coding style:
https://kernel.org/doc/html/latest/process/coding-style.html
In general, follow the `Linux kernel coding style`_, with the
following exceptions:
* Add braces to every ``if`` and ``else`` body, even for single-line code
blocks. Use the ``--ignore BRACES`` flag to make *checkpatch* stop
complaining.
* Use spaces instead of tabs to align comments after declarations, as needed.
* Use C89-style single line comments, ``/* */``. The C99-style single line
comment, ``//``, is not allowed.
* Use ``/** */`` for doxygen comments that need to appear in the documentation.
.. _Contribution workflow:
Contribution Workflow
*********************
One general practice we encourage, is to make small,
controlled changes. This practice simplifies review, makes merging and
rebasing easier, and keeps the change history clear and clean.
When contributing to Project ACRN, it is also important you provide as much
information as you can about your change, update appropriate documentation,
and test your changes thoroughly before submitting.
The general GitHub workflow used by Project ACRN developers uses a combination of
command line Git commands and browser interaction with GitHub. As it is with
Git, there are multiple ways of getting a task done. We'll describe a typical
workflow here:
.. _Create a Fork of acrn-hypervisor:
https://github.com/projecacrn/acrn-hypervisor#fork-destination-box
#. `Create a Fork of acrn-hypervisor`_
to your personal account on GitHub. (Click on the fork button in the top
right corner of the project acrn-hypervisor repo page in GitHub.)
#. On your development computer, clone the fork you just made::
git clone https://github.com/<your github id>/acrn-hypervisor
This would be a good time to let Git know about the upstream repo too::
git remote add upstream https://github.com/projectacrn/acrn-hypervisor.git
and verify the remote repos::
git remote -v
#. Create a topic branch (off of master) for your work (if you're addressing
an issue, we suggest including the issue number in the branch name)::
git checkout master
git checkout -b fix_comment_typo
#. Make changes, test locally, change, test, test again, ...
#. When things look good, start the pull request process by adding your changed
files::
git add [file(s) that changed, add -p if you want to be more specific]
You can see files that are not yet staged using::
git status
#. Verify changes to be committed look as you expected::
git diff --cached
#. Commit your changes to your local repo::
git commit -s
The ``-s`` option automatically adds your ``Signed-off-by:`` to your commit
message. Your commit will be rejected without this line that indicates your
agreement with the `DCO`_. See the `Commit Guidelines`_ section for
specific guidelines for writing your commit messages.
#. Prepare patches for e-mail submission and send to the projectacrn
mailing list for review
git format-patch
#. Once the patch is past review, the maintainer will commit the patch
Commit Guidelines
*****************
Changes are submitted as Git commits. Each commit message must contain:
* A short and descriptive subject line that is less than 72 characters,
followed by a blank line. The subject line must include a prefix that
identifies the subsystem being changed, followed by a colon, and a short
title, for example: ``doc: update wiki references to new site``.
(If you're updating an existing file, you can use
``git log <filename>`` to see what developers used as the prefix for
previous patches of this file.)
* A change description with your logic or reasoning for the changes, followed
by a blank line.
* A Signed-off-by line, ``Signed-off-by: <name> <email>`` typically added
automatically by using ``git commit -s``
* If the change addresses an issue, include a line of the form::
Fixes #<brief description about the reported issue>.
All changes and topics sent to GitHub must be well-formed, as described above.
Commit Message Body
===================
When editing the commit message, please briefly explain what your change
does and why it's needed. A change summary of ``"Fixes stuff"`` will be rejected.
.. warning::
An empty change summary body is not permitted. Even for trivial changes, please
include a summary body in the commmit message.
The description body of the commit message must include:
* **what** the change does,
* **why** you chose that approach,
* **what** assumptions were made, and
* **how** you know it works -- for example, which tests you ran.
For examples of accepted commit messages, you can refer to the acrn-hypervisor GitHub
`changelog <https://github.com/projectacrn/acrn-hypervisor/commits/master>`__.
Other Commit Expectations
=========================
* Commits must build cleanly when applied on top of each other, thus avoiding
breaking bisectability.
* Each commit must address a single identifiable issue and must be
logically self-contained. Unrelated changes should be submitted as
separate commits.
* You may submit pull request RFCs (requests for comments) to send work
proposals, progress snapshots of your work, or to get early feedback on
features or changes that will affect multiple areas in the code base.
Identifying Contribution Origin
===============================
When adding a new file to the tree, it is important to detail the source of
origin on the file, provide attributions, and detail the intended usage. In
cases where the file is an original to acrn-hypervisor, the commit message should
include the following ("Original" is the assumption if no Origin tag is
present)::
Origin: Original
In cases where the file is imported from an external project, the commit
message shall contain details regarding the original project, the location of
the project, the SHA-id of the origin commit for the file, the intended
purpose, and if the file will be maintained by the acrn-hypervisor project,
(whether or not Project ACRN will contain a localized branch or if
it is a downstream copy).
For example, a copy of a locally maintained import::
Origin: Contiki OS
License: BSD 3-Clause
URL: http://www.contiki-os.org/
commit: 853207acfdc6549b10eb3e44504b1a75ae1ad63a
Purpose: Introduction of networking stack.
Maintained-by: acrn-hypervisor
For example, a copy of an externally maintained import::
Origin: Tiny Crypt
License: BSD 3-Clause
URL: https://github.com/01org/tinycrypt
commit: 08ded7f21529c39e5133688ffb93a9d0c94e5c6e
Purpose: Introduction of TinyCrypt
Maintained-by: External

View File

@ -0,0 +1,17 @@
/* Custom CSS */
code {
font-family: Monaco,Menlo,Consolas,"Courier New",monospace;
background-color: #D8D8D8;
padding: 0 0.25em 0 0.25em;
}
pre.fragment {
display: block;
font-family: Monaco,Menlo,Consolas,"Courier New",monospace;
padding: 1rem;
word-break: break-all;
word-wrap: break-word;
white-space: pre;
background-color: #D8D8D8;
}

View File

@ -0,0 +1,21 @@
<!-- HTML footer for doxygen 1.8.13-->
<!-- start footer part -->
<!--BEGIN GENERATE_TREEVIEW-->
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
<ul>
$navpath
<li class="footer">$generatedby
<a href="http://www.doxygen.org/index.html">
<img class="footer" src="$relpath^doxygen.png" alt="doxygen"/></a> $doxygenversion </li>
</ul>
</div>
<!--END GENERATE_TREEVIEW-->
<!--BEGIN !GENERATE_TREEVIEW-->
<hr class="footer"/><address class="footer"><small>
$generatedby &#160;<a href="http://www.doxygen.org/index.html">
<img class="footer" src="$relpath^doxygen.png" alt="doxygen"/>
</a> $doxygenversion
</small></address>
<!--END !GENERATE_TREEVIEW-->
</body>
</html>

View File

@ -0,0 +1,56 @@
<!-- HTML header for doxygen 1.8.13-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen $doxygenversion"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<!--BEGIN PROJECT_NAME--><title>$projectname: $title</title><!--END PROJECT_NAME-->
<!--BEGIN !PROJECT_NAME--><title>$title</title><!--END !PROJECT_NAME-->
<link href="$relpath^tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="$relpath^jquery.js"></script>
<script type="text/javascript" src="$relpath^dynsections.js"></script>
$treeview
$search
$mathjax
<link href="$relpath^$stylesheet" rel="stylesheet" type="text/css" />
$extrastylesheet
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<!--BEGIN TITLEAREA-->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<!--BEGIN PROJECT_LOGO-->
<td id="projectlogo"><img alt="Logo" src="$relpath^$projectlogo"/></td>
<!--END PROJECT_LOGO-->
<!--BEGIN PROJECT_NAME-->
<td id="projectalign" style="padding-left: 0.5em;">
<div id="projectname">$projectname
<!--BEGIN PROJECT_NUMBER-->&#160;<span id="projectnumber">$projectnumber</span><!--END PROJECT_NUMBER-->
</div>
<!--BEGIN PROJECT_BRIEF--><div id="projectbrief">$projectbrief</div><!--END PROJECT_BRIEF-->
</td>
<!--END PROJECT_NAME-->
<!--BEGIN !PROJECT_NAME-->
<!--BEGIN PROJECT_BRIEF-->
<td style="padding-left: 0.5em;">
<div id="projectbrief">$projectbrief</div>
</td>
<!--END PROJECT_BRIEF-->
<!--END !PROJECT_NAME-->
<!--BEGIN DISABLE_INDEX-->
<!--BEGIN SEARCHENGINE-->
<td>$searchbox</td>
<!--END SEARCHENGINE-->
<!--END DISABLE_INDEX-->
</tr>
</tbody>
</table>
</div>
<!--END TITLEAREA-->
<!-- end header part -->

View File

@ -0,0 +1,8 @@
# CWP Hypervisor Documentation {#index}
Clearwater Pass is a flexible and lighweight hypervisor, built with
real-time, functional safety, and security in mind. It streamlines
embedded development through a scalable open source reference platform
that addresses embedded developers' needs.

File diff suppressed because it is too large Load Diff

2461
doc/doxyfile Normal file

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,10 @@
.. _getting_started:
Getting Started
###############
This Getting Started Guide (GSG) provides information for setting up
your host development computer with the needed software and tools for
developing with Project ACRN. We'll also provide setup
instructions for the targetted hardware platform, and running a sample
application on this platform.

View File

@ -0,0 +1,16 @@
.. _hypervisor_primer:
Hypervisor Developer Primer
###########################
This Developer Primer introduces the fundamental components and
virtualization technology used by this open source reference hypervisor
stack. Code level documentation and additional details can be found by
consulting the :ref:`hypercall_apis` documentation and the source code
in GitHub.
The Hypervisor acts as a host with full control of the processor(s) and
the hardware (physical memory, interrupt management and I/O). It
provides the Guest OS with an abstraction of a virtual processor,
allowing the guest to think it is executing directly on a logical
processor.

BIN
doc/images/ACRNlogo.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.5 KiB

32
doc/index.rst Normal file
View File

@ -0,0 +1,32 @@
.. _ACRN_home:
Project ACRN documentation
##########################
Welcome to the Project ACRN (version |version|) documentation.
For information about the changes and additions for releases, please
consult the published :ref:`release_notes` documentation.
Source code for Project ACRN is maintained in the
`Project ACRN GitHub repo`_, and is provided under the `BSD 3-clause license`_ (as found in
the LICENSE file in the project repo).
.. _BSD 3-clause license:
https://github.com/projectacrn/acrn-hypervisor/blob/doc/master/LICENSE
.. _Project ACRN GitHub repo: https://github.com/projectacrn
Sections
********
.. toctree::
:maxdepth: 1
introduction/index.rst
getting_started/index.rst
hypervisor_primer/index.rst
release_notes.rst
contribute.rst
api/index.rst

View File

@ -0,0 +1,32 @@
.. _introduction:
Introducing Project ACRN
########################
The Project ACRN Embedded Hypervisor is a flexible and lighweight bare
metal hypervisor, built with real-time, functional safety, and security
in mind. It streamlines embedded development through a scalable open
source reference platform that addresses embedded developers' needs.
This open source embedded hypervisor defines a software architecture for
running multiple software subsystems managed securely on a consolidated
system (by means of a virtual machine manager), and defines a reference
framework Device Model implementation for devices emulation.
This embedded hypervisor is type-1 reference hypervisor, running
directly on the system hardware. It can be used for building software
defined cockpit (SDC) or In-Vehicle Experience (IVE) solutions running
on Intel Architecture Apollo Lake platforms. As a reference
implementation, it provides the basis for embedded hypervisor vendors to
build solutions with an open source reference I/O mediation solution,
and provides auto makers a reference software stack for SDC usage.
This embedded hypervisor is a partitioning hypervisor reference stack,
also suitable for non-automotive IoT & embedded device solutions. It
will be addressing the gap that currently exists between datacenter
hypervisors, hard partitioning hypervisors, and select industrial
applications. Extending the scope of this open source embedded
hypervisor relies on the involvement of community developers like you!
This embedded hypervisor is able to support both Linux* and Android* as
a Guest OS, managed by the hypervisor, where applications can run.

4
doc/release_notes.rst Normal file
View File

@ -0,0 +1,4 @@
.. _release_notes:
Release Notes
#############

36
doc/static/acrn-custom.css vendored Normal file
View File

@ -0,0 +1,36 @@
/* -- Extra CSS styles for CWP content (RTD theme) ----------------------- */
/* make the page width fill the window */
.wy-nav-content {
max-width: none;
}
/* make .. hlist:: tables fill the page */
table.hlist {
width: 95% !important;
}
/* override rtd theme white-space no-wrap in table heading and content */
th,td {
white-space: normal !important;
}
/* dbk tweak for doxygen-generated API headings (for RTD theme) */
.rst-content dl.group>dt, .rst-content dl.group>dd>p {
display:none !important;
}
.rst-content dl.group {
margin: 0 0 12px 0px;
}
.rst-content dl.group>dd {
margin-left: 0 !important;
}
.rst-content p.breathe-sectiondef-title {
text-decoration: underline; /* dbk for API sub-headings */
font-size: 1.25rem;
font-weight: bold;
margin-bottom: 12px;
}
.rst-content div.breathe-sectiondef {
padding-left: 0 !important;
}

4
doc/static/jquery.js vendored Normal file

File diff suppressed because one or more lines are too long