Re: Requiring systemd for the gnome-settings-daemon power plugin

[Lennart Poettering <mztabzr 0pointer de>]

On Sat, 20.10.12 09:21, Jasper St. Pierre (jstpierre mecheye net) wrote:

> 
> (Somehow you manage to reply with "Florian Max"@gmail, "Florian
> Mullner"@gmail, and "Florian Muller"@gnome. I won't question it)
> 
> On Fri, Oct 19, 2012 at 1:15 PM, Florian Müllner <fmuellner gnome org> wrote:
> > On Fri, Oct 19, 2012 at 7:10 PM, Jasper St. Pierre
> > <jstpierre mecheye net> wrote:
> >> This is what I feel. DBus is our system abstraction layer. I feel that
> >> making ConsoleKit support the logind interface wouldn't be that big of
> >> a patch and solve this issue, at least.
> >
> > Unless I'm mistaken ConsoleKit only provides a subset of logind's
> > functionality though.
> 
> logind provides the union of UPower and ConsoleKit, no? I wonder if it
> would make sense to have a separate org.freedesktop.powerd interface
> that UPower would provide, then.

logind only took over calls to suspend/hibernate the machine from
upower. Stuff like battery management and suchlike remains in upower and
doesn't belong in logind.

logind never was intended to be an abstraction layer of any kind. In the
contrary, in order to keep the stack thin we export a lot of things that
do not really apply to non-Linux, or are hard to translate. That's stuff
like the cgroup path we expose for sessions, but plays much farther into
the logic even, in that we build on the Linux audit framework, or expose
calls such as GetSessionByPID() which securely determine the session ID
of a PID. Something like that is hard to implement if the underlying OS
doesn't have anything like cgroups which allows us to attach a session
id safely and securely to processes and where unprivileged processes
cannot escape. We also implement multi-seat based on udev device paths
and that's directly visible in the API. Then, logind hooks into the
handling of the ACPI keys and things like that, which might have
counterparts on other Unixes, but not obvious ones (and the key handling
*is* actually exposed in the API). The low-level C API we expose (which
can be used as more lightwight, passive way to watch session/user/seat
states in addition to D-Bus) exposes concepts as systemd unit names, and
is built around inotify. And the list goes on...

Some of these APIs could be turned into NOPs on non-Linux, or faked, or
one could find alternatives for. But the gist simply is: logind and its
APIs is not portable to non-Linux really. It never was intended to
be. When we started to work on it we tried to figure out what precisely
we wanted to do with logind, and one of the first things we found was
that multi-seat should work right-away, and not be an afterthought. If
you think about that, then you are in device management land. And if you
are in device management land, then portability is a foreign country.

So yupp, I am sorry to say, but logind is something that is in both code
and API Linux-specific (heck, even systemd-specific), and porting it to
other systems will necessarily be a painful.

Note that many of the other APIs we came up with in the systemd context
are actually designed to be mostly portable to other Linuxes/Unixes, for
example hostnamed, timedated and localed, because it was easy there, and
there was no reason to break portability of the APIs, but for logind
this didn't appear like a good option for us, if we wanted to get the
Linux story right.

For a list of the interfaces systemd and the portability of them we have
this list BTW:

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart

If portability matters for tracking seats/sessions/logins, yadda yadday,
then it has to take place at the client side I am sure. logind's bus
interfaces and C interfaces are not the right place. Sorry.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.