[Dnsmasq-discuss] RFC: allowing arbitrarily long options
Neil Jerram
neil at tigera.io
Fri Jan 19 11:19:30 GMT 2018
Thanks Simon!
On Thu, Jan 18, 2018 at 10:50 PM Simon Kelley <simon at thekelleys.org.uk>
wrote:
> Patch applied.
>
>
> Cheers,
>
> Simon.
>
> On 18/01/18 14:15, Neil Jerram wrote:
> > On Sun, Jan 14, 2018 at 10:35 PM Simon Kelley <simon at thekelleys.org.uk
> > <mailto:simon at thekelleys.org.uk>> wrote:
> >
> > 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>
> > > <mailto: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.
> >
> >
> > 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.
> >
> > So I believe the patch is good - please would you consider it for
> merging?
> >
> > Many thanks - Neil
> >
> >
> >
> > 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>
> > > <mailto: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>
> > > <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk
> > <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>>
> > >
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20180119/378a8ecf/attachment.html>
More information about the Dnsmasq-discuss
mailing list