On Mon, 13.01.14 22:58, Zbigniew Jędrzejewski-Szmek (zbys...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel