On Fri, Nov 28, 2014 at 4:32 PM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > 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. > > [snip] > > 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.
+1 > >> 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. Do you really think logind and systemd are the only pieces of C software that struggle with strings or config parsing? Those are definitely a couple of things that could be split out into a separate library so we all do not have to either (a) suffer through it, tediously writing another solution or (b) throw our software in systemd's git repo and use the same release cycle and license and all the other implications of being in the same repo (including not having commit access to your own software automatically). The config aspects especially so. It would be very positive if software knew they could just depend on a really simple library and get config parsing for basically free, since then users would eventually only have to know how to write one config format and software would only have to know how to read (parse) that same one. I do not know why I am discussing this here though, haha. Cheers, -- Cameron Norman -- 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/CALZWFRJu892a xx8auf+epvnggs2bts10fg4xkuqfoeof...@mail.gmail.com