On Sat, 20.10.12 09:21, Jasper St. Pierre (jstpie...@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 <fmuell...@gnome.org> wrote: > > On Fri, Oct 19, 2012 at 7:10 PM, Jasper St. Pierre > > <jstpie...@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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list