On Wed, Mar 11, 2015 at 01:18:37PM +0100, Max wrote: > 23.02.2015 13:29, Lennart Poettering пишет: > > On Mon, 23.02.15 11:30, Max ([email protected]) wrote: > > > >> Hi. > >> > >> I've got question partially inspired by recent posts to this ML from some > >> troll > >> without shift on his keyboard :) > >> > >> It's been mentioned that calls like sd_listen_fds(0) and others become > >> NOOP when > >> socket activation is not available due to lack of systemd. Which is fine > >> but leads to > >> rather inflated code as in here: > >> http://0pointer.de/blog/projects/socket-activation.html > >> > >> Is there some wrapper library which hides this boilerplate from developers? > >> > >> I mean instead of writing every time code like > >> > >> if (sd_listen_fds(0) > 1) { > >> ... // error > >> } else if (n == 1) > >> ... // systemd OK > >> else { > >> ... // fallback to legacy > >> } > >> > >> > >> I'd really prefer to use something like: > >> > >> int fd = listen_on_fd_with_or_without_systemd(...); > >> > >> which effectively incorporates all the fallback-to-legacy logic. > >> > >> The same question, naturally, applies to non-scocket-activation daemons. > >> > >> I've tried to search for it but unfortunately came up with nothing so I'd > >> appreciate > >> links to such projects or to documentation which would explain why this > >> kind of > >> wrapper is really stupid idea :) > > For testing purposes we do provide the "systemd-activate" tool to run > > socket activated daemons without socket activation. > > > > I am not really sure thought whether we should provide more than > > that. > > I'm pretty-sure you shouldn't - I'm afraid I've been unclear. I rather though > that > such wrapper library might exist as a part of some other project which aims to > simplify support both systemd and legacy system. Or it might have been > developed > while porting some code to systemd as an effort to try to preserve backward > compatibility. I don't really think this belongs to systemd itself. Internal or external to systemd is not the question.
The real problem is listed in the paragraph quoted below: the details of opening of sockets are specific to an application, so the wrapper library could only provide a set of helper functions which wrap BSD socket API, but this API is already as simple as possible, so there is nothing to be gained in doing that. > > The thing is simply that I cannot see how an API we would > > provide could be any simpler than the BSD socket API is on its own. If > > you want to listen on something, you need socket(), maybe a couple of > > setsockopt()s, a bind() and a listen(). Any API that would wrap that > > would kinda need the same amount of function calls, hence wouldn't be > > any shorter or easier with it... Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
