[Dnsmasq-discuss] RFC: allowing arbitrarily long options

Simon Kelley simon at thekelleys.org.uk
Sun Jan 14 22:35:04 GMT 2018


On 14/01/18 18:14, Neil Jerram wrote:
> Thanks for looking at this, Simon.  Some thoughts below...
>  
> On Sat, Jan 13, 2018 at 5:34 PM Simon Kelley <simon at thekelleys.org.uk
> <mailto:simon at thekelleys.org.uk>> wrote:
> 
>     I'm in favour, in theory at least, of removing arbitrary limits.
>     Experience has shown that no matter how big, someone, somewhere, will
>     always find them. The code originally used a fixed buffer which happened
>     to be unused at that point, to reduce the memory footprint. Whilst
>     dnsmasq is still intended to be "small", small is a relative thing, and
>     absolutely, rather bigger than it was 15 years ago, so allocating a big
>     enough buffer is fine.
> 
>     In this case, though, as you hint, it's likely that shell limits will
>     also be a problem. Even eliminating that by using configuration files,
>     you still have very long lines, which is ugly.
> 
>     Can't we solve this problem by allowing repeated interface names, so
> 
>     --bridge-interface=eth1,alias-1,alias-2
> 
>     becomes identical to
> 
>     --bridge-interface=eth1,alias-1
>     --bridge-interface=eth1,alias-2
> 
>     the patch to implement that is probably smaller than your offering.
> 
> 
> It looks like a nice alternative, but note that it doesn't help at all
> with any shell limit.  (In fact it would hit any such limit sooner.)  So
> I think this is a matter of what you think is more elegant for dnsmasq
> itself; particularly in the configuration file context where shell
> limits don't apply.
>  
> 
> 
> 
>     Maybe we should do both?
> 
> 
> In principle I'm happy to code up and test multiple solutions here; it's
> not a large amount of work in any case.  So please do let me know what
> you would prefer.

I'll take both, for preference.

Actually - no. You test the long-options patch and I'll take that. I'll
do the split-into-multiple lines one.


Cheers,

Simon.

> 
> Best wishes - Neil
>  
> 
> 
> 
>     On 07/01/18 14:25, Neil Jerram wrote:
>     > Calico [1] with OpenStack
>     > (https://docs.projectcalico.org/v2.6/getting-started/openstack/) uses
>     > dnsmasq with a very long --bridge-interface option:
>     >
>     >
>     --bridge-interface=<context-if-name>,<alias-if-name>,<alias-if-name>,...,
>     >
>     > where each occurrence of ",<alias-if-name>" occupies 15
>     characters, and
>     > there can in principle be as many <alias-if-name>s as you can have VMs
>     > on a single OpenStack compute host.  Currently an option arg is
>     limited
>     > in dnsmasq to 1025 chars overall, which only allows for 67
>     > <alias-if-name>s, which is not necessarily enough, on a powerful
>     compute
>     > host.
>     >
>     > So I wonder what folk would think about reallocating as necessary to
>     > allow an option arg to be arbitrarily long?  (Or at least, as long as
>     > getopt and the containing shell will allow.)  For reference I've
>     > attached a patch that I think would implement that - but I haven't yet
>     > been able to test it at all, so please don't merge it yet!
>     >
>     > Thanks in advance for your thoughts!
>     >       Neil
>     >
>     >
>     >
>     > _______________________________________________
>     > Dnsmasq-discuss mailing list
>     > Dnsmasq-discuss at lists.thekelleys.org.uk
>     <mailto: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
>     <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
>     http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 




More information about the Dnsmasq-discuss mailing list