[DTrace-devel] [PATCH v2 09/20] port: add daemonization support code

[Nick Alcock]

On 20 Sep 2022, Kris Van Hees stated:

> On Wed, Sep 07, 2022 at 01:59:57PM +0100, Nick Alcock via DTrace-devel wrote:
>> This assists in writing reliable daemons, providing a close_range() that
>> works on older glibc/kernel combinations, and a daemonize() which
>> provides a synchronization pipe down which error messages can also be
>> sent, so that errors occurring after daemonize() is called but before
>> the daemon is fully working can be reliably reported.
>> 
>> (This needs a bit of extra Makeconfig support code to let us verify not
>> only that close_range() is present in libc, but that it's present in the
>> headers and has the right prototype. The history of close_range is a
>> right tangled mess...)
>
> I would prefer the Makeconfig support to be in its own patch, and split the
> rule into two rules: check_header_rule and check_symbol_rule.  It seems too
> specific to me to have a rule that checks both, and I think you can do it with
> two rules

Alas no, because it's quite possible (and indeed common) to have a
header that contains a macro that changes what symbol is needed, and
this is pervasive in glibc in particular: so in order to do the library
part you need to do the header part too; and if you're already doing
both in the same rule, there's no point splitting off the
header-checking part because you'd just be doing it twice.

Splitting it though, that makes sense (done).

>            and then use the resulting data to make the right decision on what
> code to generate for close_range().

... I think we're already doing that bit? We don't care about the 'we
have a header but no library implementation' case, nor the 'we have a
library implementation but no header' case: both of these must be
treated as if we have neither (and in both cases it means the glibc
installation is broken, so we don't actually care about it). The
complexity here is 'header+library', 'at least one of those missing,
close_range syscall present' and 'neither of these, do it by hand'.