[systemd-devel] libsystemd-daemon wrapper

[Max]

23.02.2015 13:29, Lennart Poettering пишет:
> On Mon, 23.02.15 11:30, Max (maxim.suraev at campus.tu-berlin.de) 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.

>  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...
>
> Lennart
>