[snip] > Is this really necessary? We're not talking about a shell commandline > here, but an array of null terminated strings. If it's a restriction > placed by dnsmasq itself, then we should just disallow ' ' during > parsing rather than silently changing it, to avoid surprises. > > Well, I've been thinking about this a little bit more and I guess it *may* be better either to fail with some libvirt's virterror saying that spaces are not allowed in the TXT record name and value or to change the spaces to dashes (-) instead of undescores (_) - I guess this looks better. Also, if we add support for configuring other DNS related things we should consider: 1) TXT records 2) SRV records 3) PTR records 4) NAPTR records 5) CNAME records which is basically adding 5 new DNS records only since I see no point in changing port, query-port and edns UDP packet max size and as I already mentioned this patch should be about DNS options only and the rest of the options should be covered by a separate patch so this should be adding only the DNS records AFAIK. Also, I've been talking to Jirka Denemark (jdenemar) about this and he told me some time ago somebody wanted to pass arguments directly to XML file and spawn dnsmasq with them which would, on the one hand, add "flexibility" by directly setting up the parameters to the dnsmasq however this is the implementation issue since if we change usage of dnsmasq to usage of something else with some other parameters it would be fail because it won't be compatible so I guess adding design like: <dns> <txt ...> ... </dns> would be much better than having dnsmasq arguments directly in the XML. So basically having some new elements like: <dns> <txt name="some-name" value="some-value" /> <srv service="_service" prot="_prot" domain="domain" target="target" port="port" priority="priority" weight="weight" /> <ptr name="name" target="target" /> <naptr name="name" order="order" preference="pref" flags="flags" service="svc" regexp="re" replacement="rep" /> <cname cname="cname" target="target" /> </dns> would serve the purpose of this. What do you think about such an implementation? Would this be good for v2 of the patch? :) Thanks, Michal -- Michal Novotny <minovotn@xxxxxxxxxx>, RHCE Virtualization Team (xen userspace), Red Hat -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list