On Sat, Nov 29, 2014 at 11:51:56AM +0100, Martin Steigerwald wrote:
> Am Samstag, 29. November 2014, 01:32:22 schrieb Zbigniew Jędrzejewski-Szmek:
> > 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.
>
> Thank you for your explaination. I do not agree, as it still seems to be done
> this way out of technical convenience. And I think thats not enough of a
> reason. And, in addition to that this is PID 1, not the usual application –
> and even there… in KDE / Plasma world developers are spending *a lot of
> energy* over the last years and still to separate out things which leads to
> KDE Frameworks 5, i.e. to specifically do things that aren´t convenient in
> the
> short run.
Hi,
you seam to treat "technical convenience" as something of not
particular importance. But in software development "technical
convenience" is often the thing that makes project that is finished in
reasonable time and fun to work at and maintainable without tearing your
hair out.
You are essentially arguing that systemd developers (which includes me
btw) should take upon themselves additional work to maintain stable
APIs for internal components and also port systemd to other systems. The
first one is quite a lot of work, but feasible. It would probably by
less useful than you think though. The parts that are generally useful
and stable, like journal client API, logind client API, some utilities
that were in libsystemd-daemon, libsystemd-id128, are already provided
as shared libraries. New dbus client library is also slated to become
public when its ready and kdbus is upstreamed. Various dbus apis
are documented and stable. The parts that remain are really internal
and fast-changing stuff. I mentioned config file parsing and string
handling - those are not general purpose functions, they support
*systemd* config file syntax and are refactored and changed whenever
it is useful for the rest of the code. It's true that they could be
useful for other projects, but at a fairly heavy price. It would come
in two "installments": one, developers would have to diverge from work
on new features, bug fixes, documentation, or whatever, and spend
"*a lot of energy*" on this and the bugs it introduces by itself
instead. And two, fixed API for low-level internal stuff would create
a gorset and slow down systemd development. You could argue the same
for the linux kernel, but Linus is pretty adamant about not providing a
stable internal API.
The second part, making systemd portable, has already been widely
discussed. There are significant technical reasons why systemd is
Linux only. And the potential "recepients", like BSD, don't seem to be
interested anyway.
So yeah, we'll have to agree to disagree.
> However, some questions:
>
> So the systemd --user functionality does not add much to the binary size? And
> is the detection of the use case systemd binary runs in reliable? What
> additional failure cases for the necessary PID 1 functionality does combining
> these functionalities create?
Detection is trivial: getpid() == 1. From the top of my head, I don't recall
problems going in this direction. There were a few bugs the other way - where
--user or --test modes would attempt to do more stuff then they should, because
some part of the code was not properly conditionilized.
>
> > > 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.
>
> None of like string handling and configuration file parsing seems to be that
> special that it needs to be implemented (again?) just for systemd in my
> oppinion. The problem of INI file parsing has been solved before, the problem
> of string handling as well, a dozen of times maybe.
Systemd has some special requirements. The main one that rules out many
existing libraries is complete oom safety: memory allocation or any
other resource error has to be caught and reported to the caller. The
INI-file syntax that is supported is rather specialized too. Most other
shared functionality is rather specfic to systemd too. Those are those little
bits and pieces which accumulate in any project, I think this is normal
and unavoidable.
> KDE and GNOME if to stay portable need several code paths for using systemd
> on
> Linux and something else elsewhere additional stuff, like the session
> handling
> things. Thus systemd pushes responsibility for platform adaptability upwards
> in the stack, and urges other systems to re-implement the same interfaces…
> without, actually having seeked any agreement on those with the BSD or Hurd
> folks.
Well, this type of development, where you discuss, plan upfront, and then
pick the *lowest common denominator*, which is unavoidable if consensus is
required, is what we had before. This project chooses to go for the best
that the Linux kernel, glibc, util-linux, seccomp, gcc, and other dependencies
can offer. I expect that you'll agree with me that a lot of that functionality
wasn't widely used. Systemd chooses to expose them, even if it makes
it nonportable.
> But I think in either case it is healthy for me to accept you have or having
> explained a different oppinion (is it yours?). And healthy for you to accept
> that I have a different oppinion.
Of course I accept that you have a different opinion. I'm not even
particularly trying to convince you, but rather to describe our motivations
and the situation as I see it to other people. I am one of the
developers of systemd, and even tough I can't speak for the
project as a whole, afaik others see things in a similar way.
> For acknowledgement of the different oppinions I highly applaud the decision
> to
> have mutiple init systems for Jessie at least. The other distribution that
> switched as far as I read didn´t even care about that.
>
> Would it be easier or technically convenient to just support just one system?
> Likely. Would it be more healthy for the project as a whole: I don´t think so.
I have a different view on that. I think that doing a split between
sysvinit and systemd is going to be maintainance nightmare. It will
mean that systemd support will be riddled with hooks to synchronize
state with other systems, and advanced systemd functionality will not
be used. But hey, I'm just a spectator here, so I keep this mostly to
myself. I know why (and how) Debian project picked this course. A
decision how to proceed has been made, and discussing it endlessly
post factum would be a waste of time.
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/20141129181249.gb23...@in.waw.pl
