diff options
author | Bernd Weimer <bernd.weimer@pelagicore.com> | 2019-09-25 11:18:08 +0200 |
---|---|---|
committer | Bernd Weimer <bernd.weimer@pelagicore.com> | 2019-09-25 18:59:30 +0200 |
commit | 5f05117fb8c31ad58937d6b5bd55139a697c2673 (patch) | |
tree | c2901f3121dee0baf8b92abf08ade4d0fdcdaa67 | |
parent | ea7811529421975182f3de519da36ea610844eb9 (diff) |
Fix issues in container documentation
Change-Id: I2c0fd0ec92cc06475b37ee157f95f2bff8a1c851
Reviewed-by: Kavindra Palaraja <kpalaraja@luxoft.com>
-rw-r--r-- | doc/container.qdoc | 22 | ||||
-rw-r--r-- | examples/applicationmanager/softwarecontainer-plugin/doc/src/softwarecontainer-plugin.qdoc | 22 | ||||
-rw-r--r-- | src/plugin-interfaces/containerinterface.cpp | 9 |
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. */ |