Re: [Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.
Kevin's analysis is spot-on, as is his patch, which I've just applied. Cheers, Simon. On 26/10/2018 00:24, Kevin Darbyshire-Bryant wrote: > > >> On 25 Oct 2018, at 21:38, Kevin Darbyshire-Bryant >> wrote: >> >> 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 > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.
On Oct 25, 2018, at 4:24 PM, Kevin Darbyshire-Bryant wrote: > > > >> On 25 Oct 2018, at 21:38, Kevin Darbyshire-Bryant >> wrote: >> >> 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.. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.
> On 25 Oct 2018, at 21:38, Kevin Darbyshire-Bryant > wrote: > > 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 0001-my-try-at-nofork.patch Description: 0001-my-try-at-nofork.patch ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.
> On 25 Oct 2018, at 20:33, Shankar Unni wrote: > > On Oct 24, 2018, at 2:49 PM, Simon Kelley wrote: > >> […] >> 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.. A quick glance at the code suggests you’ve misunderstood. The compile time option ’NO_FORK’ is designed for systems that don’t have a fork system call….which is unusual to say the least. A fair amount of code is *added* if NO_FORK is NOT defined… or to put in clearer English, the code to support ‘fork’ is added in unless NO_FORK is defined. The run-time option OPT_NO_FORK aka ‘-k’ is to prevent dnsmasq forking and as you say is used by some process management daemons to determine if a process under its control has died or not. My reading of the code suggests that removing ’NO_FORK’ build option does NOT remove ‘-k’ OPT_NO_FORK run-time option. I think Openwrt is safe. There will be a loud scream from me if it isn’t :-) Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.
On Oct 24, 2018, at 2:49 PM, Simon Kelley wrote: > […] > 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.. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Compile-time options - taming the combinatorial explosion.
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. signature.asc Description: OpenPGP digital signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
