<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Jan 14, 2018 at 10:35 PM Simon Kelley <<a href="mailto:simon@thekelleys.org.uk">simon@thekelleys.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14/01/18 18:14, Neil Jerram wrote:<br>
> Thanks for looking at this, Simon. Some thoughts below...<br>
> <br>
> On Sat, Jan 13, 2018 at 5:34 PM Simon Kelley <<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a><br>
> <mailto:<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>>> wrote:<br>
><br>
> I'm in favour, in theory at least, of removing arbitrary limits.<br>
> Experience has shown that no matter how big, someone, somewhere, will<br>
> always find them. The code originally used a fixed buffer which happened<br>
> to be unused at that point, to reduce the memory footprint. Whilst<br>
> dnsmasq is still intended to be "small", small is a relative thing, and<br>
> absolutely, rather bigger than it was 15 years ago, so allocating a big<br>
> enough buffer is fine.<br>
><br>
> In this case, though, as you hint, it's likely that shell limits will<br>
> also be a problem. Even eliminating that by using configuration files,<br>
> you still have very long lines, which is ugly.<br>
><br>
> Can't we solve this problem by allowing repeated interface names, so<br>
><br>
> --bridge-interface=eth1,alias-1,alias-2<br>
><br>
> becomes identical to<br>
><br>
> --bridge-interface=eth1,alias-1<br>
> --bridge-interface=eth1,alias-2<br>
><br>
> the patch to implement that is probably smaller than your offering.<br>
><br>
><br>
> It looks like a nice alternative, but note that it doesn't help at all<br>
> with any shell limit. (In fact it would hit any such limit sooner.) So<br>
> I think this is a matter of what you think is more elegant for dnsmasq<br>
> itself; particularly in the configuration file context where shell<br>
> limits don't apply.<br>
> <br>
><br>
><br>
><br>
> Maybe we should do both?<br>
><br>
><br>
> In principle I'm happy to code up and test multiple solutions here; it's<br>
> not a large amount of work in any case. So please do let me know what<br>
> you would prefer.<br>
<br>
I'll take both, for preference.<br>
<br>
Actually - no. You test the long-options patch and I'll take that. I'll<br>
do the split-into-multiple lines one.<br></blockquote><div><br></div><div>I have (or in fact my colleague has) successfully tested this now (with a real OpenStack rig, 90 cirros VMs at the same time on a GCE n1-standard-64 compute node), with no further changes to the patch that I attached before.</div><div><br></div><div>So I believe the patch is good - please would you consider it for merging?</div><div><br></div><div>Many thanks - Neil</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<br>
><br>
> Best wishes - Neil<br>
> <br>
><br>
><br>
><br>
> On 07/01/18 14:25, Neil Jerram wrote:<br>
> > Calico [1] with OpenStack<br>
> > (<a href="https://docs.projectcalico.org/v2.6/getting-started/openstack/" rel="noreferrer" target="_blank">https://docs.projectcalico.org/v2.6/getting-started/openstack/</a>) uses<br>
> > dnsmasq with a very long --bridge-interface option:<br>
> ><br>
> ><br>
> --bridge-interface=<context-if-name>,<alias-if-name>,<alias-if-name>,...,<br>
> ><br>
> > where each occurrence of ",<alias-if-name>" occupies 15<br>
> characters, and<br>
> > there can in principle be as many <alias-if-name>s as you can have VMs<br>
> > on a single OpenStack compute host. Currently an option arg is<br>
> limited<br>
> > in dnsmasq to 1025 chars overall, which only allows for 67<br>
> > <alias-if-name>s, which is not necessarily enough, on a powerful<br>
> compute<br>
> > host.<br>
> ><br>
> > So I wonder what folk would think about reallocating as necessary to<br>
> > allow an option arg to be arbitrarily long? (Or at least, as long as<br>
> > getopt and the containing shell will allow.) For reference I've<br>
> > attached a patch that I think would implement that - but I haven't yet<br>
> > been able to test it at all, so please don't merge it yet!<br>
> ><br>
> > Thanks in advance for your thoughts!<br>
> > Neil<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Dnsmasq-discuss mailing list<br>
> > <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <mailto:<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a>><br>
> > <a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
> ><br>
><br>
><br>
> _______________________________________________<br>
> Dnsmasq-discuss mailing list<br>
> <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <mailto:<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a>><br>
> <a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
><br>
<br>
</blockquote></div></div>