[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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 16, 2014 at 04:41:48PM +0100, Lennart Poettering wrote:
> 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...
Yes, it does. Thank you for the nice summary.

I am also a bit worried about so-bumps: currently we have very nice backwards
compatibility, without any API removals. -daemon, -id128, -journal, -login
are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
keep this way, among other reasons, because it's much bigger, and much more
experimental.

Zbyszek