On Thu, Nov 27, 2014 at 10:02:06PM +0100, Martin Steigerwald wrote:
> And well, I also wonder why systemd --user functionality is in the *same*
> binary than the PID 1 stuff… but well… I brought this upstream to no avail.
OK, since this is a different forum, let me go over the reasons once again.
The code paths in systemd which differ between --system and --user are
relatively small. One part that is the table of paths where to load
units from (/etc/systemd/system vs. /etc/systemd/user, /run/systemd/system
vs $XDG_RUNTIME_DIR/systemd/user, etc). Another part says (grossly simplyfying)
if ("--system" && !test_mode && !virtualized_in_container())
setup_filesystems();
But those are just a few (important, but still) parts of the code. The
majority, like the unit dependency logic, starting of processes,
notifications from services, opening of sockets, watching of paths,
etc, etc, are all shared. Actually systemd --user is probably closer
to systemd --system running in a container than to systemd --system
running on the host, because both run without full privileges and
simply skip mounting of various things and other low-level setup.
In this scenario it is natural to structure the code as a single binary
that conditionalized parts of it logic as necessary.
> At least the logind stuff appears to be separate:
Yes, logind does not share many high-level code paths with the systemd
binary, so it is natural to keep them separate.
OTOH, systemd and systemd-logind use the same primitives like string
handling, configuration file parsing (including the logic of drop-in
directories and /etc-overrides-/run-overrides-/usr/lib), and a bunch
of other utility functions, which are provided by the shared systemd
libraries, so it is much easier to develop them in a single repository.
I hope this explains things.
Zbyszek
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141129003222.gh12...@in.waw.pl
