[systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_message_get_cookie.xml man/sd_bus_new.xml man/sd_bus_open_user.xml man/sd_bus_request_name.xml src/libsystemd src/libsystemd-bus src/libsystemd-dhcp src/libsystemd-rtnl src/systemd TODO

[Lennart Poettering]

On Mon, 13.01.14 22:58, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> Eeeh, why? This new name suggests that this libary is for systemd
> functionality. But so far it is a generic. Also, we have
> libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library,
> I'd much prefer to have it separated, if I'm using it for something not-systemd
> related.

So, this is really hard to keep seperate. The thing is that much of this
is such basic functionality that the libraries require that
functionality from each other. For example, it's certainly a good idea
to provide sd-event hookup for all our libraries that can integrate in
an event loop. WHich would suggest we'd make all those libraries depend
on libsystemd-bus. But then, we'd also like to make use of the calls
from libsystemd-login from sd-bus, since we provide
sd_bus_creds_new_from_pid() and friends. And there you have your cyclic
dep... And this is the smae for id128 and the others....

(We currently avoid these issues via a varity of unsatisfactory hacks:
for example, we don't provide any sd-event integration, and expect
consumers to do this on their own. Or, for the libsystemd-login case we
actually have the real code in src/shared/cgroup-util.c and have
libsystemd-login just a thin wrapper around it)

There are more problems this generates, for example, we link all of
src/shared/*.c into each of these libs, and then let the linker remove
all functions agin that are unused by the specific libs. This sounds
nice, but actually just means that a lot of functions are in memory a
number of times because they exist the same way in all our libraries.
This is sometimes quite ridiculous, for example for libsystemd-id128
which is kinda trivial but still pulls in a copy of its own of much of
src/shared/*.c.

So I am pretty sure libsystemd-id128, libsystemd-login,
libsystemd-journal should just end up in a single libsystemd.so together
with the event loop, the bus, the asyncns stuff and more. All this
functinality requires each other, and should nto pull in its own copy of
src/shared/*.c each time.

There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff. libsystemd-dhcp
however really sounds like something that will always be consumer of services, never
provider of services from this new libsystemd.so, and the set of
programs making use of it will always be very small, so we can and
should certainly keep it a seperate lib.

I hope this makes some sense...

Lennart

-- 
Lennart Poettering, Red Hat