summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorBernd Weimer <bernd.weimer@pelagicore.com>2019-09-25 11:18:08 +0200
committerBernd Weimer <bernd.weimer@pelagicore.com>2019-09-25 18:59:30 +0200
commit5f05117fb8c31ad58937d6b5bd55139a697c2673 (patch)
treec2901f3121dee0baf8b92abf08ade4d0fdcdaa67
parentea7811529421975182f3de519da36ea610844eb9 (diff)
Fix issues in container documentation
Change-Id: I2c0fd0ec92cc06475b37ee157f95f2bff8a1c851 Reviewed-by: Kavindra Palaraja <kpalaraja@luxoft.com>
-rw-r--r--doc/container.qdoc22
-rw-r--r--examples/applicationmanager/softwarecontainer-plugin/doc/src/softwarecontainer-plugin.qdoc22
-rw-r--r--src/plugin-interfaces/containerinterface.cpp9
3 files changed, 28 insertions, 25 deletions
diff --git a/doc/container.qdoc b/doc/container.qdoc
index 246fc82c..dd6322b7 100644
--- a/doc/container.qdoc
+++ b/doc/container.qdoc
@@ -38,13 +38,15 @@ simple as a Unix process.
\section1 Predefined Containers
-The application manager comes with a one built-in container type: the \c process container,
+The application manager comes with one built-in container type: the \c process container,
that spawns a new Unix process to execute the requested binary.
In addition, you can find a basic integration of Pelagicore's
-\l{https://github.com/Pelagicore/softwarecontainer}{software-containers} in \c
-examples/softwarecontainers. This can be used as a blueprint to either create a customer-specific
-production version of a softwarecontainers plugin, or to integrate another container solution.
+\l{https://github.com/Pelagicore/softwarecontainer}{SoftwareContainer} in \c
+examples/applicationmanager/softwarecontainer-plugin. For more information, see
+\l{SoftwareContainer Plugin Example}. This example can be used as a blueprint to either create a
+customer-specific production version of a SoftwareContainer plugin, or to integrate another
+container solution.
\section1 Extend with Container Plugins
@@ -60,8 +62,8 @@ TARGET = mycontainer-plugin
QT += appman_plugininterfaces-private
\endcode
-Then, you only have to implement two classes that derive from \c ContainerInterface
-and from \c ContainerManagerInterface respectively:
+Then, you only have to implement two classes that derive from \l ContainerInterface
+and from \l ContainerManagerInterface respectively:
\code
#include <QtAppManPluginInterfaces/containerinterface.h>
@@ -91,8 +93,8 @@ in multi-process mode:
locations before passing them on to the container. The table below lists the relevant
environment variables.
\li To support hardware OpenGL acceleration, the container needs to have access to the necessary
- device. For GPUs that follow Linux standards, such as Intel, make sure to have /c{/dev/dri/*}
- available within the container.
+ devices. For GPUs that follow Linux standards, such as Intel, make sure to have
+ \c{/dev/dri/*} available within the container.
\li You have to implement PID mapping in your plugin; unless your container solution shares its
PID namespace with the rest of the ssytem. This is necessary if you want to make use of the
application manager's security features. Each connection coming into the application manager
@@ -119,7 +121,7 @@ the application. A custom container plugin must forward these variables or adjus
\li Always set to \c{wayland}.
\row
\li \c{QT_IM_MODULE}
- \li Not set, but explicitly unset by the application manager. Make sure to leave it unset it, to
+ \li Not set, but explicitly unset by the application manager. Make sure to leave it unset, to
use the automatic Wayland input method implementation.
\row
\li \c{DBUS_SESSION_BUS_ADDRESS}
@@ -233,7 +235,7 @@ control which container integration is used:
each map has a single mapping only. While this single mapping is awkward, it is necessary to
preserve the order of the mappings. Each key is interpreted as a standard Unix wildcard
expression that is matched against the application ID. The first match stops the algorithm
- and the mapping's value is used as the container integration ID. If no matches are found,=
+ and the mapping's value is used as the container integration ID. If no matches are found,
the resulting containter integration ID is an empty string.
\badcode
diff --git a/examples/applicationmanager/softwarecontainer-plugin/doc/src/softwarecontainer-plugin.qdoc b/examples/applicationmanager/softwarecontainer-plugin/doc/src/softwarecontainer-plugin.qdoc
index 72fc309a..8b136749 100644
--- a/examples/applicationmanager/softwarecontainer-plugin/doc/src/softwarecontainer-plugin.qdoc
+++ b/examples/applicationmanager/softwarecontainer-plugin/doc/src/softwarecontainer-plugin.qdoc
@@ -30,12 +30,12 @@
\example applicationmanager/softwarecontainer-plugin
\brief Learn how to integrate Software Containers with the Application Manager.
\ingroup applicationmanager-examples
-\title Software Container Plugin example
+\title SoftwareContainer Plugin Example
\section1 Introduction
-This example shows how to integrate \l{https://github.com/Pelagicore/softwarecontainer
-{Pelagicore's Software Containers} with the Application Manager.
+This example shows how to integrate \l{https://github.com/Pelagicore/softwarecontainer}
+{Pelagicore's SoftwareContainers} with the Application Manager.
\note As a prerequisite, familiarize yourself with \l{Containers} beforehand.
@@ -45,7 +45,7 @@ capability definition is in the JSON manifest file located in
The Wayland/OpenGL passthrough is tested against Intel GPUs and VMWare's virtual GPU.
-\section1 Run the Software Container Agent
+\section1 Run the SoftwareContainer Agent
To run the softwarecontainer-agent, you must start it as root. By default, this agent registers
itself on the system D-Bus. So, you need to have a policy file in place, to allow the agent to
@@ -54,7 +54,7 @@ register itself on the system-bus.
If you want to run the agent on the session bus instead, via the \c{--session-bus} parameter,
then you have to add the following lines to one of your \c config.yaml files:
-\code
+\badcode
containers:
softwarecontainer:
dbus: 'session'
@@ -65,15 +65,15 @@ Otherwise, the container setup fails due to the missing \c{io.qt.ApplicationMana
capability.
Make sure that the agent has access to the same session bus that the application manager uses,
-if you intend on forwarding this bus. If the agent is run as root, but the application manager is
-a non-root user, this can be tricky -- since the default session bus policy in most Linux distros
+if you intend on forwarding this bus. If the agent is run as root, but the application manager
+isn't, this can be tricky -- since the default session bus policy in most Linux distros
disallows root to access user session busses. However, you can workaround this issue by adding
an \c{<allow user="root"/>} policy within the \c{<policy context="default">} element in
\c{/etc/dbus-1/session.conf}.
Additionally, make sure to tell the agent about your environment, when running it via sudo:
-\code
+\badcode
sudo XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR
DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS softwarecontainer-agent -m
/path/to/application-manager/examples/softwarecontainer-plugin/service-manifest.d/
@@ -82,7 +82,7 @@ DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS softwarecontainer-agent -m
On the Application Manager side, you need to activate the plugin by adding a line similar to the
one shown below, to one of your \c config.yaml files:
-\code
+\badcode
plugins:
container: [ "/path/to/libsoftwarecontainer-plugin.so" ]
\endcode
@@ -92,12 +92,12 @@ configuration. For more information, see \l{Container Selection Configuration}.
To simplify developing on the desktop, normally, you want your \c $HOME directory mounted into
the container in \c read-only mode. This way, you don't have to install your application manager
-into \c{/usr/} after every build. This behavior only works, given that your build direcctory is
+into \c{/usr/} after every build. This behavior only works, given that your build directory is
located somewhere in \c{$HOME}, otherwise the container won't see the appman-launcher-qml binary.
This behavior is \b not enabled by default; but you can activate it with the following lines in
one of your \c config.yaml files:
-\code
+\badcode
containers:
softwarecontainer:
bindMountHome: yes
diff --git a/src/plugin-interfaces/containerinterface.cpp b/src/plugin-interfaces/containerinterface.cpp
index d5009720..0415f5d8 100644
--- a/src/plugin-interfaces/containerinterface.cpp
+++ b/src/plugin-interfaces/containerinterface.cpp
@@ -300,8 +300,9 @@ ContainerManagerInterface::~ContainerManagerInterface() { }
The application-manager will only ever call this function once for any given instance.
This function should return \c true in case it succeeded or \c false otherwise. In case it
- returns \c true, the implementation needs to either emit the started() or errorOccurred() signal
- (can be delayed) in response to this call.
+ returns \c true, the implementation needs to either emit the started() or
+ \l{QProcess::errorOccurred()}{errorOccurred()} signal (can be delayed) in response to this
+ call.
\sa QProcess::start()
*/
@@ -330,7 +331,7 @@ ContainerManagerInterface::~ContainerManagerInterface() { }
/*! \fn void ContainerInterface::kill()
- Called by the application-manager, if it wants to kills the current process within the
+ Called by the application-manager, if it wants to kill the current process within the
container, causing it to exit immediately.
On Unix, the equivalent would be sending a \c SIGKILL signal.
@@ -435,6 +436,6 @@ ContainerManagerInterface::~ContainerManagerInterface() { }
In case the \a debugWrapperCommand is not empty, the plugin is requested to execute the binary
set by ContainterInterface::setProgram using this debug-wrapper. The plugin is responsible for
- combining both and by handling the replacement of \c{%program%} and \c{%arguments%}. See the
+ combining both and for handling the replacement of \c{%program%} and \c{%arguments%}. See the
\l{DebugWrappers} {debug-wrapper documentation} for more information.
*/