On 06/03/13 15:55, Lennart Poettering wrote:
>> Terminology: do we have a good piece of jargon for the thing represented
>> by a login1.User and an XDG_RUNTIME_DIR?
>
> 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 :-)
>> If you're going this route, I don't think there'd be much point in
>> introducing dbus-daemon --user, DBUS_BUS_USER, DBUS_USER_BUS_ADDRESS and
>> so on, just to be aliases for the session equivalents - just say "on
>> systems where it is managed by systemd, the 'session bus' is actually a
>> per-login1.User bus" and be done with it.
>
> That sounds like an OK approach, but might be confusing?
No more confusing than having DBUS_BUS_USER and DBUS_BUS_SESSION which
are not-so-secretly the same thing, IMO. Everyone's going to call it the
session bus anyway, because that name has been around for years and is
in everyone's source code.
>> In a "user bus" world, it'll still be necessary for, e.g. regression
>> tests to start an isolated mini-environment
>
> WE have "--session --address=" already, so doing env var tricks might
> not even be necessary.
dbus-daemon has that, but dbus-daemon is easy, because there are only
one-and-a-half implementations (gdbus-daemon is the half, it's a
minimal-functionality reimplementation intended for regression tests and
Windows).
I'm more concerned with how a regression test tells all its libraries,
helper subprocesses, etc. - many of which are D-Bus session clients - to
*use* the isolated mini-environment, and not stray into the real D-Bus
session, or the real $U (same definition as above). At the moment, the
answer is "set some environment variables".
I would like this to remain true in a `systemd --user` world, because
environment variables automatically propagate from parent process to
child process without extra effort; and I would like the set of
environment variables required to be somewhat stable, rather than
frequently growing new ones. XDG_*_HOME were a big step forwards in
terms of making regression tests live in an isolated mini-environment
while using a bounded set of variables.
>> 3. Remote X11.
>
> I was always of the opinion on that busses should stay local, and only
> very specific busses should ever become networked (such as what mango
> lassi has been doing).
Yeah, I would tend to agree.
> 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.
> 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.
S
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
