On 18.8.2016 14:28, Mark Andrews via RT wrote:
> On Thu Aug 18 01:23:49 2016, pspacek@redhat.com wrote:
>> On 17.8.2016 20:41, Evan Hunt via RT wrote:
>> I fetched 3390d74e33385337631b19e68760025e0ca5d6ec from Git and
>> confirm that
>> it fixes the problem in parser.
>>
>> The new header isc/errno.h works fine if I install it manually. It
>> does not
>> get installed using 'make install' - I think that this deserves one
>> more patch.
> 
> addressed

I confirm it works for me. Now the plugin should be build-able with BIND 9.11rc1.


Now I started to play with parser a little bit more and I wonder if there is a
way to pass file + line information from "parent" config object to the plugin
so the error reporting could give meaningful results.

bin/named/server.c:configure_dyndb() is now calling cfg_obj_asstring() before
the data are given to the plugin so all auxiliary information from cfg_obj_t
are lost.

Would it help to pass plain cfg_obj_t instead of string to plugins? (The
plugin can call cfg_obj_asstring() if desired.)

I'm not sure... Is there a way to take cfg_type_bracketed_text and feed it
into parser again while supplying own cfg_type_t? I mean, is it possible to
call the parser and tell it to re-interpret cfg_type_bracketed_text as some
other cfg_type_t?

That would improve user experience and general debugging as well because
plugins would be able to print nice error messages using cfg_obj_log() etc.


Wondering a bit more about this, there is an alternative:
Plugin API could contain new symbol (provided by the plugin) which would
contain cfg_type_t for plugin's top-level config. This symbol could be used
instead of cfg_type_bracketed_text by the named's parser and resulting cfg_obj
could be just passed to the plugin (e.g. attached to dctx).

As a side-effect it would enable users to use "include" in plugin config (I
guess).


What do you think? What are viable alternatives?

Have a nice weekend!

-- 
Petr Spacek  @  Red Hat