archives/steamos-manager
archives/steamos-manager
2
0
Fork 1
mirror of https://gitlab.steamos.cloud/holo/steamos-manager.git synced 2025-07-10 00:20:29 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update the README file with how things have changed lately.

Browse source 
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:
Jeremy Whiting 2024-05-15 08:30:09 -06:00
parent fe2475a4eb
commit e0f9019172
1 changed files with 13 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

29
README.md
View file

@ -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.