mirror of
https://gitlab.steamos.cloud/holo/steamos-manager.git
synced 2025-07-10 00:20:29 -04:00
Update the README file with how things have changed lately.
Most of the text of the README was written before we landed on not using a config file for each api to make it a simple jump table. Also added some bits about user daemon vs root daemon.
This commit is contained in:
parent
fe2475a4eb
commit
e0f9019172
1 changed files with 13 additions and 16 deletions
29
README.md
29
README.md
|
@ -1,26 +1,23 @@
|
|||
This is the SteamOS Manager.
|
||||
|
||||
It is a small daemon that's sole purpose is to give Steam something with a dbus
|
||||
It is a small daemon that's sole purpose is to give Steam something with a DBus
|
||||
api that runs as root and can do things to the system without having to have
|
||||
hard coded paths and dbus apis in the Steam client itself.
|
||||
hard coded paths and DBus apis in the Steam client itself.
|
||||
|
||||
It is a thin wrapper around other scripts and dbus apis that provides feedback for
|
||||
each dbus method it implements.
|
||||
It is a mostly thin wrapper around other scripts and DBus apis that provides feedback for
|
||||
each DBus method it implements.
|
||||
|
||||
How it works:
|
||||
|
||||
The SteamOS Manager reads various config files (one per thing that it needs to support)
|
||||
that have a DBus method defined in them along with the parameters needed for that method.
|
||||
When it reads each config file it creates a DBus method on it's interface that other applications
|
||||
and processes can call. When each method is called, either the script referred to in the config
|
||||
is called and output and exit codes are given back to the caller, or a dbus method is called
|
||||
from another daemon and the feedback it gets is given back to the caller.
|
||||
The SteamOS Manager runs as root and exposes a DBus api on the system bus.
|
||||
Another instance runs as deck user and exposes a DBus api on the session bus with
|
||||
a few extra methods. These methods run directly in the user daemon as deck user. All
|
||||
other apis forward to the root daemon via it's DBus api.
|
||||
|
||||
To add a new method:
|
||||
|
||||
Add a new config file (more on this later once we flesh out details) with the method name, parameters
|
||||
and what should happen when it is called. For most dbus type methods, the incoming method and parameters
|
||||
will likely closely resemble what we call on another daemon. The purpose of this is to make it flexible
|
||||
for various operating systems to do things their own way. For example on a system that doesn't want to
|
||||
include systemd many systemd type operations could be carried out by scripts instead of calling a systemd
|
||||
dbus api.
|
||||
To add a new method that doesn't require root privileges add it to the user daemon's DBus api
|
||||
directly.
|
||||
|
||||
To add a new method that does require root privileges add it to the root daemon's DBus api and it will
|
||||
be exposed automatically in the user daemon.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue