~kennylevinsen/seatd-devel

1

Questions about seatd

Ihor Antonov
Details
Message ID
<3561460.kQq0lBPeGt@tycho>
DKIM signature
missing
Download raw message
Hey kennylevinsen and folks!

I learned about seatd project from emersion.fr 's blog.
I am curious to learn more about your project but the readme does not expand 
on why seat management is important. Perhaps this is implicitly understood by 
a savvy developer, but no much for people who are not closely familiar with 
nuts and bolts of Linux (and FreeBSD for that matter) "under-the-hood".


I do apologize upfront if my questions sound stupid :)  Please feel free to 
throw links at me if some concepts are better explained elsewhere.
Here they go:

- Why seat management is a thing? What problems does it solve? What things are 
impossible/hard to do without seat management?

- How does seatd fit into the larger picture of "non-systemd" world? (I assume 
that this project is designed to exist outside of systemd "ecosystem") Do you 
plan integration with other service managers (runit/openrc/s6/bsd init)?

- I assume that seat management problem has, among other things, something to 
do with device management. Is integration with eudev/mded/bsd devd planned?

- Does seat management benefit from having an advanced IPC machinery like dbus?


I am in the middle of a stagnant act of systemd rebellion (tried Gentoo, 
considering FreeBSD) . I am curious about all development in this space for 
personal curiosity and maybe for participating in a OS level opensource 
project (although I am scared of C a bit :) 


Thanks

------
Ihor
Details
Message ID
<H0L3KQ.8EO3ABVY6CGC3@kl.wtf>
In-Reply-To
<3561460.kQq0lBPeGt@tycho> (view parent)
DKIM signature
pass
Download raw message
On Fri, Nov 13, 2020 at 20:42, Ihor Antonov 
<ihor.antonov@epicgames.com> wrote:
> - Why seat management is a thing? What problems does it solve? What 
> things are
> impossible/hard to do without seat management?

The purpose of seat management is:

1. To grant access to devices without being root.

2. To mediate sharing of these devices amongst multiple users/sessions, 
revoking/reissuing access as needed.

3. (Optional) To support multi-session and multi-seat setups.

You cannot avoid having to be root to use the full DRM API (e.g. 
drmSetMaster), and you cannot avoid having to do a handoff dance in 
order to properly pause your device usage and let others take over.

Even if you do not use seatd or logind, you are still using a form of 
seat management. The "direct" session backend in wlroots is in fact 
just an internal seat management daemon: You start the compositor 
setuid'd to root, and wlroots forks off a seat management daemon that 
only serves a single session, which it then talks to over IPC before 
dropping privileges. It does most of what it needs to do, but it is 
fragile: If your compositor is buggy or crashes, you risk having the 
"seat" being in a broken state, unable to perform cleanup/handover.

seatd - and (e)logind for that matter - formalizes and isolates this 
daemon, and adds support for multiple clients. Compositors can then run 
as a regular user, as the root part is handled by the daemon. This 
setup also provides much better resilience to e.g. compositor crashes, 
as the daemon just sees a disconnect and can do the appropriate cleanup.

The last, optional point is about allowing e.g. to sets of 
keyboards/gpus/... to run different, isolated user sessions on the same 
machine, as well as allowing the same VT (or no VT in CONFIG_VT=n 
configurations) to run multiple sessions one at a time.

> - How does seatd fit into the larger picture of "non-systemd" world? 
> (I assume
> that this project is designed to exist outside of systemd 
> "ecosystem") Do you
> plan integration with other service managers (runit/openrc/s6/bsd 
> init)?

libseat and seatd depend only on libc, and work on both Linux and 
FreeBSD.

libseat abstracts all seat management away into a simple library. 
Compositor developers can then get seatd, (e)logind, and even direct 
backend support for free. They avoid having to reimplement things, get 
what is likely a much more robust "direct" backend than what they 
currently have (in the form of an embedded seatd instance), and 
users/distros can pick at compile-time which libseat backends they 
want. If they pick (e)logind, they will get a dependency on 
libelogind/libsystemd, otherwise the only dependency is libc.

seatd is the smallest possible seat management daemon, doing absolutely 
nothing more than it needs to. It has no idea what a service manager is 
- start it however you like, or use the scripts/service manager 
integrations included in the package for your distro of choice.

You can see which distros/OS's have packages here: 
https://repology.org/project/seatd/versions

> - I assume that seat management problem has, among other things, 
> something to
> do with device management. Is integration with eudev/mded/bsd devd 
> planned?

It doesn't interact with anything like that. Device *discovery* is 
currently left up to the compositor.

A udev replacement would be a different project altogether.

> - Does seat management benefit from having an advanced IPC machinery 
> like dbus?

No.

> I am in the middle of a stagnant act of systemd rebellion (tried 
> Gentoo,
> considering FreeBSD) . I am curious about all development in this 
> space for
> personal curiosity and maybe for participating in a OS level 
> opensource
> project (although I am scared of C a bit :)

There are also other non-systemd distributions, such as Void Linux and 
Alpine Linux, in case FreeBSD does not work out for you.

There is no reason to be scared of C, especially if you are not writing 
security critical software.

Best regards,
Kenny Levinsen
Reply to thread Export thread (mbox)