[Dnsmasq-discuss] Enable HAVE_IPSET by default

Simon Kelley simon at thekelleys.org.uk
Fri Apr 12 10:27:08 BST 2013


On 12/04/13 02:12, richardvoigt at gmail.com wrote:
> All of this suggests that to minimize the number of combinations but
> not bloat the binary, there ought to be a `MINIMAL` or `TEENY_TINY`
> macro that unsets HAVE_IPSET and a bunch of other similar non-critical
> features.

But which ones? The minimal binary excludes DHCP, so it's useful for 
some people but not many, I venture. I think the current scheme is about 
optimal.

1) By default include everything that doesn't involve an extra library 
dependency.

2) Provide controls to individually enable the library-dependent 
features and disable the others.

Anyone who cares about size really needs to decide exactly what they want.

Cheers,

Simon.

>
> On Thu, Mar 21, 2013 at 6:23 AM, Kevin Darbyshire-Bryant
> <kevin at darbyshire-bryant.me.uk>  wrote:
>> On 21/03/2013 10:08, Simon Kelley wrote:
>>> <snip>
>>>
>>> Finally, if it's going to be on by default, and given the limited size
>>> delta/lack of library definitions, there's an argument for not making
>>> it compile-time selectable at all. Every compile-time switch
>>> contributes to the combinatorial explosion of possible binaries, and
>>> lots of bugs come from unanticipated interactions in untested
>>> compile-flag combinations.
>>>
>>>
>>> Opinions, anyone?
>>>
>>>
>>>
>>> Simon.
>>
>> Hi Simon,
>>
>> I'll express an opinion, based purely on my *very* limited experience of
>> integrating 2.66test16 into a recent version of Tomato to fix some IPv6
>> problems.  I keen an eye on latest git pushes and integrate those into
>> my own personal version for testing.  I'm very much waiting for 2.66
>> release to come out so that I can push that to the proper Tomato
>> maintainers.
>>
>> Size is a very important consideration for Tomato as some versions are
>> expected to run on a 2.4 kernel and squeeze into 3.8MB of flash rom
>> space - bytes matter.  Having said that, the Tomato developers don't
>> have to upgrade to the latest dnsmasq (have been running 2.61 for some
>> time) and the continuing support of what must be regarded as legacy
>> hardware has to come to an end sometime.
>>
>> Based very much on your 'compile time switches lead to untested
>> combinations of binaries' argument, I'd say remove it as an option and
>> make it a standard feature.
>>
>> Well it's an opinion, but what do I know :-)
>>
>> Kevin
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>




More information about the Dnsmasq-discuss mailing list