On Wed, 06.03.13 16:26, Simon McVittie (simon.mcvit...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
