[systemd-devel] RFC: user session lifetimes vs. $DISPLAY

[Lennart Poettering]

On Wed, 06.03.13 16:26, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> > logind tracks a "state" enum for each user. It is either offline,
> > lingerung, online, active, closing.
> [...]
> > So, following this terminology I'd just call the user "online" in the
> > context you were asking about.
> 
> What I'm looking for is the $U in these statements:
> 
> The $U consists of one or more overlapping login sessions, plus
> potentially some time in which it is "lingering" with no login sessions.
> XDG_RUNTIME_DIR is created at the beginning of the $U and deleted at the
> end of the $U. A `systemd --user` and a `dbus-daemon --session` run for
> the duration of the $U.
> 
> ... it's not "login session", it's not "session", "user" is confusing
> outside the context of the logind implementation (because an offline uid
> doesn't have a $U), and "user session" is confusing IMO (it sounds as
> though it might mean a login session by a uid that represents a real
> person, as opposed to root or gdm or something) - any other ideas?
> 
> It's a concept we keep talking about, so I think it deserves a name.
> Names are important :-)

"non-offline users"? ;-)

> > Note that with the kdbus stuff I assume that apps would soonishly stop
> > working across networked dbus anyway.
> 
> I don't know about anyone else's implementations, but in AF_BUS (the
> implementation by Vince Sanders et al), the modified dbus-daemon is able
> to bridge between an AF_BUS socket and any other sockets that the same
> dbus-daemon might be listening on. In particular, the AF_UNIX
> [/var]/run/dbus/system_bus_socket still works - it just won't carry any
> traffic if there are no AF_UNIX clients.

The kdbus stuff from Kay and gregkh works very differently from AF_BUS,
and is heavily focussed on CoW and zerocopy dta transfer, in order to
allow it to be useful to send substantial payloads over, rather than
just control. i.e. we want to make it useful that the camera tool can
send a JPEG over the bus, and so that this doesn't suck. And then, when
people use that, this will become highly inefficient for networked dbus.

> > For example, the new "Portals"
> > stuff from the apps context we want to use kdbus to exchange actual
> > payload data, and that wouldn't scale at all in a networked environment.
> 
> I have never heard of "Portals in an apps context", but if your data is
> particularly large (bulkier than X11, say), my advice would be to
> fd-pass a unicast socket and do your bulk traffic across that (which
> also only works locally - fine, that particular application doesn't
> support remote D-Bus). D-Bus is mainly designed to be a convenient
> control channel - it has features like broadcasts and addressing
> limiting its maximum throughput and minimum latency. For bulk data, you
> can do better.

Hmm, the "portals" stuff didn't make it to you yet? We hat this GNOME DX
hackfest a while back in brussels where we hashed out some plans for app
sandboxes. This involves "portals" which are supposed to be the primary
gateway from the app sandboxes to the rest of the OS.

https://docs.google.com/document/d/1QTgxakyUVFMkvr-xFY2Xg9lYjcJLd6kPTl3Ij5_dL7Q/pub

Well, fd passing doesn't work over the network either. And it has one
fundamental problem: the source can still change the memory it
references after the sender got it, which is risky. The CoW solution
fixes that problem: the receiver will always get a snapshot of the
memory that won't change anymore.

The sandbox stuff also means we want the kernel to enforce policy on
what is transferred. This is much easier if we use the same channel for
everything.

So, yeah, we want to make dbus efficient. Zero copy, copy on write,
scatter gather, suitable for bulk data. And we will probably quickly
start relying on this for the portals stuff.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.