[Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.

[Simon Kelley]

The dnsmasq code has a range of binary compile-time options, implemented
conventionally using the C pre-processor. These options are mutually
independent, so the numnber of different versions scales as 2^n. To keep
this managable, I'm trying to limit the number of options.

I've already removed HAVE_IPV6. This was added originally to support
very ancient embedded libc versions, and to save a few bytes on very
limited machines. I think it's reasonable to assume in 2018 that nobody
wants to eliminate IPv6 support, and that nobody is running with a libc
that doesn't know about IPv6.


The next option in my sights is NO_FORK. This produces a
mostly-functional binary that never forks any new processes. It was
added long ago to support uclinux, the MMU-less version of Linux. As far
as I can tell, MMU-less linux is a dead project, and I'm minded to
remove NO_FORK. Opinions? Is this option vital to something I'm not
aware of?



Cheers,

Simon.

[Shankar Unni]

Post by Simon Kelley
[…]
The next option in my sights is NO_FORK. This produces a
mostly-functional binary that never forks any new processes. It was
added long ago to support uclinux, the MMU-less version of Linux. As far
as I can tell, MMU-less linux is a dead project, and I'm minded to
remove NO_FORK. Opinions? Is this option vital to something I'm not
aware of?

From what i can see, this will kill off the ‘k’ option that’s used by many process-management environments. E.g. openwrt’s process management (the procd daemon) depends on the originally-launched process to stick around (it doesn’t know or care about the PID file), and does really ugly things if the PID changes after launch. It also doesn’t seem to have an option to pass in an explicit PID file to read and poll. (I just verified by removing the -k option, and it keeps spawning more and more dnsmasqs..)

If you do want to do this, it’ll probably need a few months of warning and preparation for various distros..

[Kevin Darbyshire-Bryant]

This post might be inappropriate. Click to display it.

[Kevin Darbyshire-Bryant]

I think Openwrt is safe. There will be a loud scream from me if it isn’t :-)
Cheers,
Kevin D-B

In fact to prove it to myself I had a go at removing the NO_FORK compile time option (patch attached) and had no obvious problem with the resultant binary on Openwrt.

Whether Simon implements the change as I have done or takes the opportunity to simplify things that I don’t understand I don’t know, but NO_FORK v OPT_NO_FORK are different things and OPT_NO_FORK relies on NO_FORK *NOT* being defined.

Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A

[Shankar Unni]

Post by Kevin Darbyshire-Bryant

Post by Kevin Darbyshire-Bryant
I think Openwrt is safe. There will be a loud scream from me if it isn’t :-)
Cheers,
Kevin D-B

In fact to prove it to myself I had a go at removing the NO_FORK compile time option (patch attached) and had no obvious problem with the resultant binary on Openwrt.

Thanks for confirming that, Kevin. Sorry for the quick mis-reading of the source, because I’d just been debugging around there earlier..

[Simon Kelley]

Kevin's analysis is spot-on, as is his patch, which I've just applied.


Cheers,

Simon.

Post by Kevin Darbyshire-Bryant

Post by Kevin Darbyshire-Bryant
I think Openwrt is safe. There will be a loud scream from me if it isn’t :-)
Cheers,
Kevin D-B

In fact to prove it to myself I had a go at removing the NO_FORK compile time option (patch attached) and had no obvious problem with the resultant binary on Openwrt.
Whether Simon implements the change as I have done or takes the opportunity to simplify things that I don’t understand I don’t know, but NO_FORK v OPT_NO_FORK are different things and OPT_NO_FORK relies on NO_FORK *NOT* being defined.
Cheers,
Kevin D-B
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss